DMARC explained, with a real domain

DMARC in plain English

Email was designed in the 1980s with no way to prove who sent a message. Anyone can type any address into the From: line. That's why fake invoices and "urgent request from the CEO" emails work so well.

When an email arrives claiming to be from [email protected], the receiving server (Gmail, Outlook and so on) asks three questions. You answer each one by publishing a record in your domain's DNS:

The key idea: alignment

SPF and DKIM on their own don't stop spoofing. A scammer can send from their own server, at their own domain, and pass SPF for their domain, while the From: line your staff actually see says [email protected].

Only one of the two needs to pass and align. In practice DKIM is the one to rely on, because the signature survives when email is forwarded and SPF often doesn't.

Policies and reports

The DMARC record tells receivers two things. First, the policy (p=) says what to do with email that fails:

Second, the report address (rua=): every day, the big mailbox providers send you a summary of every server that sent email claiming to be your domain, and whether it passed. That's how you find the services you forgot about (your website's contact form, your accounting system, a newsletter tool) before you switch to p=reject and accidentally block them.

Hands-on lab: send as [email protected]

Here's exactly what we did on a Windows laptop. We send with Azure Communication Services (ACS), which needs a verified custom domain. Verifying it is the part that adds the SPF and DKIM records above. The commands use PowerShell and the Azure CLI. Replace the placeholders in <angle brackets> with your own resource names.

Resolve-DnsName globalsoc.com.au -Type TXT | Select -Expand Strings          # SPF
Resolve-DnsName _dmarc.globalsoc.com.au -Type TXT | Select -Expand Strings   # DMARC
Resolve-DnsName selector1-azurecomm-prod-net._domainkey.globalsoc.com.au -Type CNAME   # DKIM → Azure's key

A verified ACS domain only sends from usernames you create, so nobody can quietly send as ceo@.

az communication email domain sender-username create `
  --email-service-name <email-service> -g <resource-group> `
  --domain-name globalsoc.com.au --sender-username blah --username blah --display-name "Blah Blah"

$cs = az communication list-key -n <communication-service> -g <resource-group> --query primaryConnectionString -o tsv
az communication email send --connection-string $cs `
  --sender "[email protected]" --to "[email protected]" `
  --subject "DMARC test" --text "Hello from blah"

In Gmail, open the email and choose ⋮ → Show original. The summary at the top is the receiving server's verdict:

SPF:   PASS with IP …
DKIM:  'PASS' with domain globalsoc.com.au
DMARC: 'PASS'

Scroll down to the Authentication-Results: header. You'll see header.d=globalsoc.com.au (who signed it) and header.from=globalsoc.com.au (what you saw). They match. That's alignment, and it's why DMARC passes.

Now send yourself an email through a service that isn't set up for your domain, such as Gmail's "Send mail as" with your company address. Open "Show original" again. DKIM will be signed by gmail.com, which doesn't match the From: domain. With p=reject, that email could be blocked. This is exactly what DMARC reports warn you about.

Within a day or two, emails with zipped XML attachments arrive at the rua address. Unzip one and you'll find a row for each server that sent email as your domain:

<row>
  <source_ip>…</source_ip>  <count>3</count>
  <policy_evaluated><dkim>pass</dkim><spf>pass</spf></policy_evaluated>
</row>
<identifiers><header_from>globalsoc.com.au</header_from></identifiers>

Rows that fail show either a service you need to fix, or someone pretending to be you.

What we're building next

Reading XML by hand gets old fast. At Global SOC we're building two tools on Azure:

1. Send-a-test-email verifier. You get a unique address, send it a normal email from your own mailbox, and within seconds see SPF, DKIM, DMARC and alignment for your real email, with plain-English fixes.
2. DMARC report dashboard. Point your rua= at us and get readable charts instead of XML: who sends as you, what's failing, and when it's safe to move to p=reject.

We'll post the build, with screenshots, here. In the meantime, our free DNS Audit checks your SPF, DKIM and DMARC records along with 40 other DNS security settings in about 10 seconds.