# DMARC setup step by step — why your mail does not arrive | RootCore LLC > SPF, DKIM and DMARC in plain language — what the records mean, the most common mistakes, and how to roll DMARC out without throwing away your own invoices. Page: https://cyber-security.rootcr.com/en/knowledge/dmarc-setup/ Updated: 2026-08-20 --- # DMARC setup: why your mail does not arrive > **In short:** SPF, DKIM and DMARC together tell the receiving mail system whether a message really came from your domain. Since 1 February 2024 Gmail requires at least SPF or DKIM from every sender, and all three from senders above 5,000 messages a day. If this is not in order, two things happen at once: your own mail lands in spam, and anyone can send mail in your company's name. Setting the records up takes a day or two; tightening takes two to four weeks — and that part must not be rushed. ## The three records, in plain language Think of your message as an envelope that gets checked at a reception desk. | Record | What it states | Its role at the desk | |---|---|---| | **SPF** | Which servers may post mail for the domain | “This courier is on our list” | | **DKIM** | A digital signature on the message | “The seal is intact, nobody touched it in transit” | | **DMARC** | What to do when the first two fail | “If it does not check out: let it through, set it aside, or send it back?” | DMARC on its own protects nothing: it builds on the SPF and DKIM results. That is why all three are needed. ## What they look like in practice **SPF** — a TXT record on the domain itself: ``` example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``` **DKIM** — a TXT record under a selector; the key comes from your mail provider: ``` selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." ``` **DMARC** — a TXT record on the `_dmarc` subdomain: ``` _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100" ``` The DMARC fields worth knowing: - **`p=`** — the policy: `none` (monitor and report only), `quarantine` (send to spam), `reject` (refuse outright). - **`rua=`** — where aggregate reports are sent. Without it you are working blind. - **`adkim=` / `aspf=`** — how strictly the domain must match: `r` (relaxed, subdomains count) or `s` (strict, exact match). - **`pct=`** — what percentage of mail the policy applies to. Useful for a gradual rollout. ## The four most common mistakes ### 1. Two SPF records on one domain The most common one, and it invalidates the lot immediately. The standard permits exactly one SPF record per domain. If your mail provider added one and your newsletter tool added another, they must be **merged**, not placed side by side: ``` "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``` ### 2. Too many DNS lookups Evaluating SPF may use at most ten DNS lookups. Every `include:` uses at least one, and some use several because they reference further. Past the tenth, evaluation fails and your message is treated as if you had no SPF at all. With many providers, the `include` list has to be trimmed. ### 3. A forgotten sender The classic case: mail is with Google, but the invoicing tool, the shop and the newsletter system send from elsewhere. SPF lists only Google, so your invoices get stuck — exactly the mail that matters most. That is why the work always starts with an **inventory**: which systems send mail in your name? ### 4. Going straight to `p=reject` It is tempting to set the strictest policy immediately. When you do, mail from your legitimate but not-yet-authenticated senders disappears too — not into spam, but for good. Rolling out DMARC is deliberately a slow process. ## The rollout ### Step 1 — inventory Write down everything that sends mail in your name: mail provider, shop, invoicing, CRM, newsletter, helpdesk, monitoring alerts. That list is the basis for SPF. ### Step 2 — fix SPF One valid record containing every legitimate sender. End it with `-all` (hard fail) or at least `~all` (soft fail); `+all` lets everyone through and is therefore pointless. ### Step 3 — DKIM on every sender It has to be enabled separately in each system, each with its own key and selector. With most providers this is one switch and one DNS record. ### Step 4 — DMARC in monitoring mode ``` "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` At this point **nothing changes in delivery**, but you start receiving daily aggregate reports on who is sending mail in your name and which senders fail authentication. This is the important phase: it is where you find out what you left off the list. Give it two to four weeks. ### Step 5 — tighten Once every legitimate sender passes in the reports, move to `quarantine`, then after a week or two to `reject`. If you want to be careful, step through with `pct=`: first a quarter of traffic, then half, then all of it. ## What to look for in the reports A DMARC report is XML and was not designed for humans. Look for two things: - **A legitimate sender that fails** — that needs fixing (a missing `include`, DKIM not enabled). - **A foreign server sending in your name** — either a forgotten system of yours, or abuse. For most clients this report brings the first surprise. If you would rather not read XML, several services translate the reports into plain language; you point the report address at them. ## Why did this suddenly become important? Because the large providers tightened up. Since 1 February 2024, Gmail requires **every sender** to have at least SPF or DKIM, a valid PTR record and a TLS connection. Anyone sending more than 5,000 messages a day to Gmail addresses needs **SPF, DKIM and DMARC** (the DMARC policy may be `p=none`), plus one-click unsubscribe in marketing mail. Spam rates reported in Postmaster Tools must stay below 0.3% — Google's own recommendation is to stay under 0.1%. The practical consequence: without authentication your mail first goes to spam, and then stops arriving at all. ## Verification: how do you know it works? 1. **Send a test message** to a Gmail and an Outlook account from each of your systems separately. 2. **Read the headers** (“Show original” in Gmail): the `Authentication-Results` line should say `spf=pass`, `dkim=pass` and `dmarc=pass`. 3. **Check that the From domain aligns** with either the SPF or the DKIM domain. This is called alignment, and it is where DMARC most often fails even when SPF and DKIM pass individually. 4. **Look at the DMARC report a week later** — it shows what your test messages cannot. ## Frequently asked questions ### I do not send newsletters. Do I still need this? Yes, for two reasons. First, invoices and automatic confirmations are mail too, and they have to arrive. Second, missing authentication is not about your sending — it is about someone else being able to send as you. ### I have a domain I never send mail from. Does it matter? Very much. Those “parked” domains are exactly the ones used for spoofing. They deserve the strictest records, because there is nothing to break: ``` "v=spf1 -all" "v=DMARC1; p=reject;" ``` ### My hosting provider already set something up. Is that not enough? Typically they add a basic SPF record for their own server. That is enough if all your mail leaves from there — but the shop, the invoicing tool and the newsletter system usually send from elsewhere. Those are precisely the senders that get left out. ### How long does the whole thing take? Setting up the records is a day or two plus a few hours of DNS propagation. The monitoring phase is two to four weeks — it cannot be skipped, because it is what protects your own mail. After that, tightening is a matter of days. ### What happens if I get it wrong? The most common consequence is that your own mail stops arriving. That is what the monitoring phase and the header checks are for: both show you the problem before your customers meet it. --- If you would rather not edit DNS records, [we will put your e-mail authentication in order](/en/email-security/) — from the inventory to `reject`, measuring all the way that your own mail keeps arriving.