How to set up DMARC (step by step)

Do this in order. Inventory who sends as the domain. Publish one SPF record. Turn on DKIM and prove it with a new message. Then publish DMARC at p=none, read what comes back, and only then tighten the policy. Skip ahead to p=reject and the invoicing tool you forgot will start bouncing.

The record lives at _dmarc plus your domain, for example _dmarc.company.com. There is one TXT record there. A second one means receivers can ignore the policy. The tag list is in RFC 7489.

1. Write down every sender

Mailbox host. Website forms. Invoices. The bank. The newsletter. The helpdesk. The scanner that emails scans. Ask the person who pays the bills as well as the person who edits DNS. They know about different systems.

Also write two names: who can change DNS, and who can open the mail admin console. A record you cannot edit is a record you do not control. Pick a shared mailbox for the reports, not a person who might leave next month.

2. Publish one SPF record

SPF is a TXT record on the domain itself that names the servers allowed to send as you. RFC 7208 says that if DNS returns more than one SPF record, the result is a permanent error. Receivers will not merge them.

Copy each sender's include from that vendor's current page. On the day this note was written, Google's help page showed v=spf1 include:_spf.google.com ~all, and Microsoft's showed include:spf.protection.outlook.com inside a record that can end in -all. Confirm both on those pages before you paste. A second product means you add its include to the same record, not a second record.

While the list is still incomplete, end the record with ~all (soft fail). When a test from each sender passes, change it to -all (hard fail). +all means anyone may send. Delete that if you find it.

include, a, mx, ptr, exists, and redirect each cost a DNS lookup. The cap is 10, and lookups inside an include count too (RFC 7208 section 4.6.4). A record over the cap can fail even when it ends in -all. Drop includes for tools you cancelled.

3. Turn on DKIM and send a new message

DKIM is a signature on the message, checked against a public key in DNS. RFC 6376 is the spec. The mail host generates the key. You publish the TXT or CNAME it gives you, under a name like selector._domainkey.company.com. Do not invent the selector.

Google's help page uses a hostname such as google._domainkey. Microsoft 365 uses selector1 and selector2. Yours may be neither. The name in the DKIM-Signature header of a message you just sent is the one that has to exist in DNS. Old mail is not signed after the fact.

In that header, d= has to be your domain. A signature that passes for the vendor's domain can look healthy and still fail DMARC alignment for you. DMARC compares that d= value, or the SPF-authenticated domain, with the address people see in From (RFC 7489 section 3.1).

4. Publish DMARC at p=none

One TXT record. Start here:

Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@company.com

Use your real report mailbox. p=none does not stop spoofing. It asks receivers to mail you XML reports about who sent as you. pct defaults to 100, meaning the policy applies to all of the mail. You do not need to set it yet.

Leave adkim and aspf off at the start. The default is relaxed alignment: a subdomain can still align with the organizational domain. Google's sample record on their setup page includes adkim=s; aspf=s, which is strict. Strict fails mail whose authenticated domain is a subdomain rather than an exact match. That is a later choice, after you know every sender aligns exactly. Do not paste the strict tags on day one just because they appeared in an example.

If the report address is on another domain, that domain must say it accepts your reports (RFC 7489 section 7.1). An address at your own domain does not need that extra TXT record.

5. Read the reports before you change p=

Give it two weeks, and a full billing cycle if invoices go out monthly. You are looking for legitimate mail that fails. Fix that sender's SPF include or DKIM before you change the policy. A report nobody opens is a reason to stay at p=none, not a reason to skip to reject.

Forwarders and some mailing lists break SPF, because the forwarder's server is not in your SPF record. DKIM often still passes if the signature was not altered. That is why you want DKIM in place before you enforce. One failed row in a report is not automatically an attacker.

6. Quarantine, then reject

p=quarantine asks receivers to treat failures as suspicious, which often means the spam folder. They do not all obey. If you want a smaller first step, pct=10 applies the policy to a slice of mail, then you raise it. pct is not a confidence score. Do not leave it at 10 and call the job done.

p=reject asks receivers to refuse failures. Move there when the reports no longer show a legitimate sender failing. Keep the rua address. The next tool someone signs up for will fail until you add its SPF and DKIM, and the reports are how you notice.

Subdomains inherit the parent policy unless you set sp=. If the apex is reject and you wanted a subdomain to stay in monitor mode, say so with sp=none on purpose and write down why.

What this does not cover

A lookalike domain (a name that resembles yours but is not yours) is not fixed by your DMARC record. DMARC applies to mail that claims to be from the domain in the record.

Google's sender guidelines say that, starting 1 Feb 2024, people who send more than 5,000 messages a day to Gmail accounts have to set up SPF and DKIM, and set up DMARC. That page says the DMARC policy can be none. A company under that volume should still do this work. The guideline is a floor for bulk mail, not a reason to skip the record. The page is Email sender guidelines.

The sequence, including MFA and offboarding, is also the checklist. What SPF, DKIM, and DMARC each check is the comparison note.