Is Your Specialist Domain Missing DMARC? Why Your Letters to GPs Hit Spam

There is a failure in medical practices that almost nobody checks for, because it produces no error message, no bounce, and no complaint you can trace. A specialist sends a reply letter to a referring GP. The letter is written, the send button is pressed, the sent folder confirms it went. And it lands in the GP's spam folder, unread, where it sits until it is auto-deleted.

Nobody is told. The specialist assumes the letter was received. The GP assumes the specialist never wrote back. And the next time that GP has a patient to refer, they quietly send them somewhere else.

I spent years as a speech pathologist before I moved into software, so I have sat on both sides of this: the clinician who assumes their correspondence arrived, and the engineer who knows exactly how mail servers decide what to trust. This piece is about the gap between those two, and about a specific, checkable, fixable reason your practice email may be silently failing.

The problem is trust, and email has almost none by default

Here is the uncomfortable foundation. The email protocol was designed in an era when nobody worried about forgery. By default, anyone can send an email claiming to be from any address. There is nothing in plain email that stops me putting your practice's address in the "from" field.

Receiving mail servers, meaning Gmail, Outlook and the systems behind GP clinical software, know this. So they spend enormous effort deciding whether an incoming message is really from who it claims to be. If they can confirm it, it goes to the inbox. If they can't, it gets treated with suspicion, and suspicion means the spam folder.

The mechanism that lets a receiver confirm you are really you is called domain authentication. It rests on three DNS records, SPF, DKIM and DMARC, and if your practice domain is missing them, you are asking every receiving server to take your identity on faith. Increasingly, they don't.

SPF, DKIM and DMARC, in plain English

You do not need to be technical to understand what these three do. Think of them as three layers of the same question: "is this email really from this domain?"

SPF (Sender Policy Framework) is a public list of which mail servers are allowed to send email on behalf of your domain. When a message arrives claiming to be from your practice, the receiver checks whether it came from a server on your list. It is the equivalent of a guest list at the door.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. The receiver can verify that signature against a public key published in your DNS, which proves two things: the message really came from your domain, and it wasn't altered in transit. It is a tamper-proof seal on the envelope.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy that ties the other two together. It tells receiving servers what to do when a message fails SPF and DKIM, whether to ignore it, quarantine it to spam or reject it outright, and it can send you reports on who is sending mail using your domain. It is the instruction sheet that says "here is how to treat anything that doesn't check out."

The important part is that all three live in your domain's DNS settings. They are not software you install or a subscription you run. They are records that either exist and are configured correctly, or don't. And for a large share of Australian practices, they don't.

This is not a rare edge case

You might assume that any professional domain has this sorted. It doesn't. According to domain-authentication tracking for Australia, roughly 72% of Australian domains have no effective DMARC, and only about 9.3% are at full enforcement. That means the large majority of Australian domains, practices included, are sending email that receiving servers cannot fully verify.

That is an adoption figure, not a promise about your open rates. But it tells you something blunt: if your practice has never deliberately configured email authentication, the base rate says you are probably in the unprotected majority. This is the default state of a domain, not a badly maintained exception.

Healthcare specifically tends to lag. In Valimail's analysis of US healthcare domains, only around 11% had DMARC at full enforcement, leaving the large majority exposed to spoofing. That figure is US-specific, not Australian, but it lines up with the direction of the Australia-wide number above, and there's no reason to think Australian healthcare is meaningfully ahead of the general domain population. The same is broadly true of MTA-STS, a related standard that enforces encrypted delivery. It's a secondary concern next to the core three, but the pattern is the same: email security is the part of the stack that healthcare consistently leaves unconfigured.

Why unauthenticated email lands in spam

Let me connect the DNS records to the spam folder directly, because this is the part that decides whether you lose referrals.

When a GP's mail server receives a letter from your practice, it runs a quiet series of checks. Does the sending server match your SPF list? Does the DKIM signature verify? Does your DMARC policy exist and pass? Each answer feeds a reputation score that decides inbox versus spam.

If your domain has no DMARC record at all, the receiver is left guessing. It cannot confirm the message is genuine, and it cannot rule out that it is a spoof of your practice. Faced with that uncertainty, especially for a domain sending health-related content to another professional inbox, the safe move for the receiver is to filter the message to spam rather than risk delivering a forgery.

The cruelty of it is the silence. A message filtered to spam is not bounced. Your mail server reports success. You get no notification, no error, nothing. From your side, the letter was sent and, as far as you know, received. The failure is invisible unless someone on the other end happens to mention it, and GPs rarely go digging in their spam folder to rescue a letter they don't know is coming.

What actually lands in spam, and what it costs

This isn't only about formal reply letters. Everything your practice sends from its domain is exposed to the same filtering:

• Reply-to-referrer letters back to the GP who sent you the patient.
• Referral acknowledgements confirming you received a referral and the patient is in your system.
• Appointment confirmations and reminders to patients.
• Results, requests, and follow-up correspondence to other practices.

Now walk through the cost of one of these going missing. A GP refers a patient to you. You see the patient, you write a clear and prompt reply letter, and it lands in the GP's spam. The GP never sees it. From their chair, they referred a patient and heard nothing back. That silence tells them you are hard work to refer to.

I wrote in a companion piece that your reply letter to the referring GP is your best marketing channel, the single most visible signal a GP gets about whether you are worth referring to again. Domain authentication is the plumbing underneath that channel. You can write the best reply letter in your specialty and it earns you nothing if the receiving server quietly bins it before the GP ever reads it.

The patient-facing side has its own cost. An appointment confirmation that lands in spam becomes a patient who isn't sure they're booked, a reminder that never arrives becomes a no-show, and a practice that looks disorganised to the patient it was trying to reassure. None of it generates a complaint you can act on. It just quietly erodes the impression that your practice has its act together.

There is a national backdrop here too. The federal government's Modernising Referral Pathways consultation reflects how much attention the reliability of referral communication is now getting in Australia. As the referral loop moves further toward digital correspondence, whether your email is trusted by the systems on the receiving end stops being a technicality and starts being part of how referable you are.

How to check your own domain

You do not need to wait for a GP to tell you something is wrong. You can check your domain yourself in a few minutes. Here is a practical checklist.

1. Send a test email to a personal Gmail account. From your practice email address, send a short message to a Gmail address you control. Open it, click the three-dot menu, and choose "Show original" (or "View source"). Near the top you will see lines for SPF, DKIM and DMARC, each marked PASS or FAIL. If any say FAIL or are absent, that is your answer.

2. Look up your DMARC record directly. Use any free DMARC or DNS lookup tool and search for a record at _dmarc.yourdomain.com.au. If nothing comes back, you have no DMARC policy at all, which is the most common finding.

3. Check your SPF record. In the same lookup tools, search your domain for a TXT record beginning with v=spf1. If it is missing, or if it doesn't include the mail provider you actually send through, that is a problem.

4. Confirm DKIM is signing your mail. DKIM is the fiddliest to check manually because it lives under a provider-specific selector, but the "Show original" test above will tell you whether your outgoing mail is being signed and verified.

5. Ask whoever manages your domain. If a web person or IT contact set up your domain, ask them plainly: "Do we have SPF, DKIM and a DMARC policy configured, and is DMARC at enforcement?" A straight answer of "yes, and DMARC is at quarantine or reject" is what you want to hear.

Here is a quick reference for reading the result:

If you run these checks and everything passes at enforcement, good. You are in the minority that has this handled, and you can stop reading. If not, this is fixable.

How to fix it

The fix is configuration, not a product. Someone with access to your domain's DNS needs to publish the right records and, crucially, get them consistent with every service that legitimately sends mail on your behalf: your email provider, your booking or reminder system, anything that sends from your address.

The sequence, done properly, looks like this. Publish an accurate SPF record listing every legitimate sender. Enable DKIM signing with your mail provider and publish the matching key. Then introduce a DMARC record, usually starting in monitoring mode (p=none) to watch the reports and confirm nothing legitimate is failing, before moving it up to enforcement (p=quarantine or p=reject) so it actually protects your delivery.

The reason this is worth doing carefully, rather than pasting in a record you found online, is that a misconfigured SPF or an over-aggressive DMARC policy can block your own legitimate mail. Done right it protects delivery; done carelessly it can make the spam problem worse. This is why the monitoring step matters.

This is exactly the kind of work that should be handled when your domain and website are set up, not bolted on after a GP complains. When we build a practice website, email authentication is part of the setup: our plans include Spam-Shield email authentication: full SPF, DKIM and DMARC so letters to GPs deliver reliably, along with custom domain setup. It sits in the Launch plan and above. The point is that your domain is configured to be trusted by the servers on the receiving end, so the correspondence you send actually arrives.

I want to be precise about what that does and doesn't promise. Authenticating your domain removes a specific, common reason mail gets filtered. It does not guarantee any particular open rate or delivery percentage, and anyone quoting you a magic number should be treated with suspicion. What it does is stop your domain from being the reason a receiving server distrusts your mail. That is a real, structural improvement, and it is one of the few deliverability levers entirely within your control.

The bottom line

The most expensive email problems are the ones that never announce themselves. A missing DMARC policy doesn't bounce your letters or throw an error. It just quietly lowers the odds that your reply to a GP, your acknowledgement of a referral, or your confirmation to a patient reaches the inbox instead of the spam folder, and it tells you nothing while it happens.

For a specialist practice, that is not a technical footnote. The referring GP who never received your letter is the referring GP who sends the next patient elsewhere. Spend ten minutes checking your own domain. If SPF, DKIM and DMARC don't all pass at enforcement, treat it as the silent leak it is.

If you would rather have it set up correctly from the start, meaning the domain, the business email and full Spam-Shield authentication so your correspondence actually lands, start with the website foundations and we will configure it as part of the build.