Your boss asked you to “secure the company email.” A lawyer mentioned DMARC. A compliance checkbox wants proof. This guide cuts straight to what to do.
Time estimate: 30-60 minutes if you have DNS access and all email providers documented. Longer if you need to audit services from scratch.
Prerequisites:
- Access to your DNS provider (Cloudflare, AWS Route 53, etc.)
- Login credentials for every email service your company uses
- List of all email senders (see Step 1)
What the three records actually do
SPF (RFC 7208) lists which mail servers are allowed to send email for your domain, as a DNS TXT record. A message from a server not on that list can be treated as suspicious.
DKIM (RFC 6376) attaches a cryptographic signature to outgoing messages. The receiving server checks that signature against a public key you publish in DNS. Forgery is detectable.
DMARC (RFC 9989) is the policy layer. Its p= tag tells receivers what to do when neither SPF nor DKIM passes in alignment with your From: domain (none, quarantine, or reject), and its rua= tag says where to send aggregate reports so you can see what’s actually happening before you tighten anything.
SPF and DKIM alone don’t stop spoofing, and p=none only watches. A quarantine or reject policy is what asks receivers to act on forged mail, and getting there starts with these three records.
Step 1: Audit who actually sends email for your domain
Before touching DNS, list every service that sends email from your domain:
- Google Workspace / Microsoft 365 (transactional, internal)
- SendGrid / Amazon SES / Postmark (product emails)
- Mailchimp / Brevo / Klaviyo (marketing campaigns)
- Any third-party CRM or helpdesk that sends notifications
Each one needs to be authorized in SPF and should sign messages with DKIM. Miss one and you’ll see failures in your DMARC reports.
Step 2: Publish an SPF record
SPF lives at the root of your domain as a TXT record. A typical record for a company using Google Workspace and SendGrid:
v=spf1 include:_spf.google.com include:sendgrid.net ~allinclude:authorizes the third-party sender’s IP ranges.~allmeans “soft fail”: treat unauthorized senders as suspicious but don’t hard reject yet.
Validation: After adding your SPF record, verify it with:
dig TXT example.com +short | grep "v=spf1"SPF limit: the spec caps you at 10 DNS lookups per evaluation across every include, a, mx, ptr, exists, and redirect term combined. Add a fourth or fifth SaaS sender and you’ll often blow past it, which turns every message into a silent permerror. See SPF permerror: why adding one SaaS tool breaks your email authentication before you add your next sender.
Step 3: Enable DKIM for each sender
Every email platform has a DKIM setup section. The process is always the same:
- Generate a key pair in the platform’s settings.
- Publish the public key as a DNS TXT record at a selector subdomain (for example
google._domainkey.example.com). - Verify in the platform dashboard.
Validation: After adding each DKIM record, verify it with:
dig TXT selector._domainkey.example.com +shortCheck Google Workspace, SendGrid, Postmark, and any other active sender. Skipping even one means DMARC failures for messages from that sender.
Step 4: Start with a monitoring-only DMARC policy
Add this TXT record at _dmarc.example.com:
v=DMARC1; p=none; rua=mailto:dmarc@example.comp=none: monitoring mode, no enforcement yet. Email still delivers.rua: where aggregate reports go (daily XML from every major mail provider).
Leave out ruf=. Forensic reports carry samples of individual failing messages, most receivers stopped sending them years ago for privacy reasons, and publishing a ruf= address you don’t actually monitor buys you nothing.
Validation: After adding DMARC, verify it with:
dig TXT _dmarc.example.com +shortDo not jump to p=reject yet. You need to see what your legitimate senders are doing first. Give it at least a month of reports before tightening policy.
Step 5: Read your reports without going blind
Raw DMARC reports are daily XML attachments. Nobody reads them by hand for long. DMARC Guardian ingests them for you and shows which senders pass and which fail, the source IPs sending on your domain’s behalf (authorized or not), and 30-day volume and pass rate per sender, showing the ones that need attention by default.
Once all legitimate senders pass, move the policy to p=quarantine, then eventually p=reject.
The reality check
| Task | Time | Notes |
|---|---|---|
| Inventory your senders | 5-15 min | Check DNS panel + every email platform you use |
| Publish SPF | 5 min | One DNS TXT record |
| Enable DKIM per sender | 10–30 min | Depends on how many senders you have |
Publish DMARC at p=none | 2 min | One DNS TXT record |
| Set up monitoring | 3 min | Point rua at a reader and let reports arrive |
The 30-minute estimate is optimistic if your senders are already on one or two platforms. It takes longer if you have many services or if DKIM isn’t yet available from older SaaS tools. Plan for 60 minutes to be safe.
What to watch in the first month
Whatever you’re using to read reports, check weekly for:
- Unknown senders: IPs you don’t recognize sending as your domain (potential spoofing, or a forgotten SaaS integration).
- Alignment failures: a service sends DKIM-signed mail, but the signing domain doesn’t match your
From:domain. - Volume drops: a sudden dip in authenticated traffic can mean a sender broke its DKIM config.
Once every known sender shows a clean pass, you’re ready to move to enforcement. See moving from p=none to p=reject safely for the rollout order, and reading DMARC aggregate reports without drowning in XML for what each field in those reports actually means.