Why this matters
Mail receivers decide whether to trust your domain by checking who sent the message and whether the message changed in transit. SPF lists the servers allowed to send for a domain. DKIM adds a signature that ties the message to a key you control. DMARC tells the receiver what to do when those checks fail and ties the result to the From header your recipient sees.
Without these records, someone can send mail that looks like it comes from your domain. Your own mail can also land in spam when a mailing tool or app server sends on your behalf and the receiver cannot verify it. DMARC also gives you reports, so you can find senders you forgot about.
The records live in DNS. You need control of the domain's DNS zone and a clear list of every system that sends mail as your domain. The work is mostly inventory and testing, not typing long strings.
Before you start
List every system that sends mail with your domain in the From address. Check the main mailbox provider, the CRM, the marketing tool, ticketing, e-signature, invoicing, monitoring, scanners and any app that sends password resets. Include agencies and contractors that send on your behalf.
Get access to DNS. You need to add TXT records at the domain root and at selector names such as selector._domainkey.example.com. Some providers use CNAME records for DKIM instead of TXT, so check what each sending service expects.
Export current DNS records before you change anything. Note existing SPF records, DKIM selectors and any DMARC record. Pick a mailbox you control for DMARC reports, such as [email protected], and make sure someone reads it. Lower the TTL on records you plan to change so fixes take effect faster.
How to do it
Work in order: SPF, then DKIM, then DMARC in monitor mode. Do not start with a strict DMARC policy. Publish records, send test mail through every sender, and read reports before you ask receivers to quarantine or reject mail.
SPF and DKIM answer different questions. SPF checks the envelope sender and the connecting IP. DKIM checks a signature over the message headers and body. DMARC passes when either SPF or DKIM aligns with the From domain. That alignment rule is why a valid SPF record for a bounce domain is not enough on its own.
The steps below cover the records and the test cycle. Keep a change log with the date, the record name, the value and the sender it supports. You will need that log when a new tool starts sending mail or when a report shows an unknown source.
- Inventory every sender first. Write down each service, its sending domain, its SPF include or IP range, and its DKIM selector. Ask each vendor for the exact DNS values it requires. Do this before you publish anything so you do not break a sender you forgot.
- Publish one SPF record. Create a single TXT record at example.com that starts with v=spf1. Add include: mechanisms for each approved sender, then end with ~all while you test. If an SPF record already exists, merge it instead of adding a second one.
- Turn on DKIM signing. Enable DKIM in the mailbox provider, marketing tool or app that sends mail and use a 2048-bit key if offered. Copy the selector and public key it gives you into DNS as a TXT record, or add the CNAME it asks for. Keep the private key in the sending service.
- Add DMARC in monitor mode. Publish a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:[email protected]. Add adkim=r and aspf=r for relaxed alignment unless you have a reason to be strict. Leave pct at the default while you collect data.
- Send test mail through each sender. Send a real message from each system to a mailbox you can inspect. Check the Authentication-Results header for spf=pass, dkim=pass and dmarc=pass. Test a reply and a forwarded message too, because forwarding can break SPF.
- Read the DMARC reports. Open the XML reports sent to your rua address or load them into a reporting tool. Look for sources with DMARC fail and for domains that pass SPF but fail alignment. Fix those senders before you change the policy.
- Tighten the policy in stages. Move to p=quarantine with a low pct, then raise pct as reports stay clean. When every real sender passes, change to p=reject. Keep the rua address in place after you tighten.
- Save the setup in a runbook. Record the final records, selector names and report contacts. Review them when you add a tool, change a vendor or see a new source in reports.
How to check it worked
Query DNS from outside your network. Use dig TXT example.com +short, dig TXT selector._domainkey.example.com +short and dig TXT _dmarc.example.com +short. You should see one SPF record, the DKIM public key and the DMARC policy.
Send a test message to a mailbox at a major provider and open the full headers. Look for Authentication-Results with spf=pass, dkim=pass and dmarc=pass for your domain. Check the From header, the Return-Path and the DKIM d= value. They should line up with the domain you meant to authenticate.
Watch reports for a few weeks. A clean report shows your known senders passing and no strange IPs. If a report shows a fail, match the IP or domain to a service in your inventory. Fix the record or remove the sender.
A DMARC record at example.com sets policy for subdomains that do not have their own record, but SPF and DKIM still need to align for each sending subdomain. If a subdomain sends mail, publish its own records or make sure its DKIM domain aligns.
Mistakes to avoid
Do not publish more than one SPF record. Two v=spf1 records cause a permanent error in many receivers. Merge every include into one record and remove old records after the TTL expires. Watch the SPF lookup limit, because each include adds DNS lookups.
Do not use +all or a bare all in SPF. Use ~all while testing and -all when the list is complete. A hard fail too early can block invoices, password resets and support replies.
Do not jump to p=reject. Start at p=none, read reports, then move to quarantine and reject. Do not publish a DMARC record without a monitored rua address, because you will be blind to failures.
Do not forget DKIM selector rotation or typo the selector name. A missing or wrong selector makes DKIM fail even when the key is valid. Keep the private key out of DNS and out of tickets. DNS holds only the public key. If you want the domain and the campaigns set up together, the Cloudverg Marketing automation build at $7,500 fixed price includes sending domain setup with SPF, DKIM and DMARC, forms, sequences and reporting. It is one option among others.
Frequently asked questions
Do I need SPF, DKIM and DMARC all at once?
Start with SPF and DKIM, then add DMARC at p=none. That gives you reports without blocking mail. Move to a stricter DMARC policy only after your real senders pass.
How long does DMARC take to work?
DNS changes take effect after the TTL you set. Reports arrive once receivers see the record and send aggregate data. Give yourself clean reports from all known senders before you tighten the policy.
What if my mail provider already sets SPF and DKIM?
Keep their records and add yours only if you send through another service. One SPF record must include every sender. DKIM selectors are separate records, so multiple senders can each have their own selector.