Stop people sending as your domain

#What DMARC actually decides

SPF answers a question about the envelope: was this server allowed to send for the domain in the return path. DKIM answers a question about a signature: was this message signed by a domain, and has it changed since. Neither question mentions the address a person sees in their mail client, and that address is the one the fraud depends on.

DMARC adds the missing step, called alignment. A message passes DMARC when SPF or DKIM passes and the domain that passed lines up with the domain in the visible From header. That is the whole mechanism, and it is why a message can pass SPF and still be a forgery of your brand: the envelope domain was the sender's own, and nobody was checking that it matched.

#What has to exist first

Publishing a DMARC record before SPF and DKIM work is the most common way to make this project fail loudly. There is nothing for DMARC to align, so every message fails, and if the policy is not none the mail disappears.

• SPF. A single TXT record on the domain listing the services that send for you, ending in -all once you are sure it is complete. The limit that catches people is ten DNS lookups: go past it and receivers return a permanent error, which most treat as having no SPF at all. Every include: spends the lookups inside its own record too, so a record that looks like eight is often over.
• DKIM. Your sending services each publish a public key at a selector and sign outgoing mail. Use 2048 bit keys, and keep the selector names straight: rotating a key means publishing a new selector, moving signing to it, and only then removing the old one.

Our SPF, DKIM and DMARC tool reads an existing record and says what each term does, counts the lookups you have already spent, and reads the key size out of a DKIM record. It also writes the records, which is the part people put off.

#Publishing the first record

The first DMARC record changes nothing about how your mail is treated, and that is the point.

v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com;

Three details are worth getting right on day one.

• The version tag is case sensitive. It must read v=DMARC1 exactly. A lowercase v=dmarc1 makes receivers discard the whole record, and the domain has no DMARC while appearing to have one.
• rua is what makes the rest possible. Without a reporting address you get no daily reports, which means no way to find the senders that would break when you tighten. This is the tag people leave out and then wonder why the project stalls.
• Leave sp alone. With no sp tag, subdomains inherit the policy. Setting sp=none under a strict p hands a forger an easy alternative: they send from a subdomain that never existed.

#What comes back, and how to read it

Within a day or two, receivers start sending aggregate reports: compressed XML, one per receiver per day, listing the source addresses that sent mail claiming to be your domain, how many messages each sent, and whether SPF and DKIM passed and aligned.

What you are looking for, in order:

1. Sources you recognise that are failing. Your invoicing system, a marketing platform, a helpdesk, the office scanner. Each one needs either an SPF entry or DKIM signing before you tighten anything.
2. Sources you do not recognise at all. Some will be forwarders, some will be genuine forgery. Volume and consistency separate them.
3. Sources that pass. The quiet majority, and the measure of how close you are.

Reports are XML because they are meant for software. A reporting service will parse them for you, and for a small domain reading the first few by hand is a useful way to see what the fields mean before you automate it.

#Finding the senders nobody remembers

Every organisation has more things sending mail as its domain than anyone can name. The reports find them, and a few are worth expecting:

• Marketing and newsletter platforms, often set up by a department rather than IT.
• Invoicing, payroll, applicant tracking and e-signature services that send on your behalf.
• The helpdesk or ticketing system that mails customers from a support address.
• Monitoring, backup and device alerts from hardware nobody has logged into for years.
• A staff member's own tool, connected with a plausible sounding address and forgotten.

As you add each one to SPF, watch the lookup count. This is where the ten lookup limit bites: a domain with six vendors is often already over it once each include is expanded, and the failure mode is not an error message, it is SPF quietly not working. Where a provider publishes IP ranges, ip4: and ip6: entries cost nothing and are worth the extra maintenance.

#Tightening, without losing mail

Once the reports show only sources you recognise, and those are passing, move up a step and wait.

v=DMARC1; p=none;       rua=mailto:dmarc@yourcompany.com;
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com;
v=DMARC1; p=reject;     rua=mailto:dmarc@yourcompany.com;

A few weeks at quarantine is enough to surface anything the reports did not. Then reject, which tells receivers to refuse a failing message outright rather than filing it in spam where somebody will eventually find it.

#What a reject policy does not stop

DMARC at enforcement removes one specific attack: someone sending mail that claims to be from your exact domain. That is worth having, and it is narrower than it sounds.

• Lookalike domains. yourcompany-invoices.example is a different domain, so your policy has no say. The attacker publishes their own records and passes their own DMARC.
• Display name spoofing. A message from an unrelated address can still show your company's name, and on a phone that name is often all the recipient sees.
• Mail from your own compromised account. It is genuinely your domain, sent through your own service, and it passes everything. This is the case DMARC cannot help with, and the one most likely to cost money.
• Inbound protection. Your policy protects other people from forgeries of you. What protects your staff is the receiving side: enforcing other domains' policies, and the checks your mail service applies.

Which is why enforcement is a floor rather than a finish line. Once a domain is at p=reject, the remaining paths are the human ones, and the way to find out how your people would handle those is to try them. That is what a phishing simulation measures.