How to Authenticate a Sending Domain: SPF, DKIM and DMARC Setup Guide

To authenticate a sending domain, you publish three DNS records that prove to Gmail, Yahoo, Outlook and every other receiving server that your messages are really yours: SPF lists the servers allowed to send for you, DKIM adds a cryptographic signature to each message, and DMARC tells receivers what to do when those checks fail. Done in one sitting, it usually takes about 30 minutes, and it is the single biggest step you can take for inbox placement.

The short version

1. Check what exists. Look up your current SPF, DKIM and DMARC records so you edit rather than duplicate them.
2. Publish one SPF record. A single TXT record at your domain root that includes every service that sends as you.
3. Publish DKIM. The selector record from your dashboard, so each message is signed.
4. Publish DMARC at p=none. Start in monitoring mode with a reporting address.
5. Verify. Run dig, then send a test message and read the headers.
6. Enforce. Review reports, then move to p=quarantine and p=reject.

What does it mean to authenticate a sending domain?

Email was designed without a way to verify who sent a message. Anyone can type your address into the From field, which is why phishing and spoofing are so common. Authentication closes that gap with three complementary checks, each answering a different question for the receiving server:

• Is this server allowed to send for this domain? That is SPF (Sender Policy Framework, defined in RFC 7208).
• Is the message genuinely from this domain and unaltered? That is DKIM (DomainKeys Identified Mail, RFC 6376).
• What should happen if either check fails, and who gets the report? That is DMARC (RFC 7489).

Receivers combine the three into a trust signal. Messages that authenticate and align with your From domain build a stable domain reputation over time. Messages that do not are filtered, delayed or rejected, and at larger volumes are now refused outright by the major mailbox providers.

SPF, DKIM and DMARC at a glance

	SPF	DKIM	DMARC
What it proves	The sending server is authorised for the domain	The message was signed by the domain and not changed in transit	The checks align with the visible From domain, and sets the policy
Where it lives in DNS	TXT record at the domain root	TXT or CNAME at selector._domainkey	TXT record at _dmarc
What is checked	Return-Path (envelope sender) domain and sending IP	Signature in the DKIM-Signature header	From header domain against SPF and DKIM results
Survives forwarding?	Usually not	Yes, if the content is not modified	Passes if DKIM passes and aligns
Main failure cause	Missing sender or more than 10 lookups	Wrong selector or key copied incorrectly	Alignment mismatch

Before you start: what you need

• Access to edit DNS for the domain (registrar, Cloudflare, cPanel or your DNS host).
• A list of every service that sends email as your domain: your MigoSMTP account, your office mail (Google Workspace or Microsoft 365), your CRM, billing and support tools.
• A mailbox to receive DMARC reports, preferably a dedicated address such as dmarc-reports at your domain.
• The SPF include and DKIM record values from the Domains page in your MigoSMTP dashboard.

Step 1: Check your current records

Duplicate records are the most common reason authentication fails. Look up what is already published before you add anything. On macOS or Linux use dig; on Windows use nslookup.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

# Windows
nslookup -type=TXT example.com

Look for any TXT record that begins with v=spf1 (SPF) and any at _dmarc that begins with v=DMARC1. If either exists, you will edit it rather than add another.

Step 2: Add your SPF record

SPF is a single TXT record at the root of your domain. It lists the services allowed to send mail using your domain in the envelope sender (the Return-Path).

SPF record syntax

v=spf1 include:YOUR-MIGOSMTP-INCLUDE include:_spf.google.com ~all

Part	Meaning
v=spf1	Required. Marks the record as SPF version 1.
include:domain	Authorises everything that domain's own SPF record authorises. Use the value from your MigoSMTP dashboard.
ip4:203.0.113.10	Authorises a specific IPv4 address or range. IPv6 uses ip6:.
a, mx	Authorises the IPs of your domain's A or MX records.
~all	Soft fail: anything not listed is suspicious but not rejected outright. Common while you are still adding senders.
-all	Hard fail: anything not listed is not authorised. Use once you are certain every sender is listed.

The 10-lookup limit

SPF evaluation may cause at most 10 DNS lookups. Every include, a, mx, exists and redirect counts, including lookups made inside the records you include. Go over and receivers return a permanent error, so SPF fails for every message. Keep the count low by removing services you no longer use, replacing a and mx with explicit ip4 ranges where stable, and moving rarely used tools to their own subdomain.

Common SPF mistakes

• Two SPF records at the same name (merge them into one).
• Using +all, which authorises the entire internet.
• Typing the include value with extra spaces or a missing colon.
• Forgetting a sender such as a billing system or help desk, so its mail fails SPF.
• Publishing SPF on the wrong name, such as the www host instead of the domain root.

Step 3: Publish your DKIM record

DKIM adds a digital signature to every message. Your sending platform signs outgoing mail with a private key it keeps secret, and you publish the matching public key in DNS so receivers can verify the signature.

Selectors and where the record goes

Each key lives under a name called a selector, in the form selector._domainkey.yourdomain.com. The selector lets you publish several keys at once and rotate them without downtime. Your MigoSMTP dashboard shows the exact name and value for your domain.

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)

TXT or CNAME?

Some platforms ask you to publish the public key directly as a TXT record. Others give you a CNAME that points to a record they host, which lets them rotate keys for you. Publish exactly the type your dashboard shows. Do not convert one into the other.

Key length and formatting

• Use 2048-bit RSA keys when available. 1024-bit keys are still accepted by many receivers but are considered weak.
• A 2048-bit key is longer than 255 characters, and a single DNS string cannot exceed 255 characters. Your DNS host must split the value into multiple quoted strings inside one TXT record. Most dashboards do this automatically; if yours does not, split it manually.
• Copy the value without added line breaks or smart quotes, and do not wrap it in extra quotation marks unless your DNS host requires them.

Rotation

Rotate DKIM keys every six to twelve months, or immediately if a private key may have been exposed. Publish the new selector first, switch signing to it, and delete the old selector only after mail signed with it has finished arriving.

Step 4: Publish your DMARC record

DMARC ties SPF and DKIM to the domain your recipients actually see in the From line, and tells receivers what to do with mail that fails. It is a TXT record at _dmarc.yourdomain.com. Start in monitoring mode so you can see who is sending as you before you enforce anything.

Name:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Tag	What it does	Typical value
v	Version. Must be first.	DMARC1
p	Policy for mail that fails: none (monitor), quarantine (spam folder) or reject (refuse).	none at first
rua	Where daily aggregate reports are sent.	mailto:dmarc-reports@example.com
ruf	Where failure samples are sent. Few receivers send these.	Optional
pct	Percentage of failing mail the policy applies to, used during gradual rollout.	25, 50, 100
sp	Policy for subdomains if different from the parent.	Same as p unless needed
adkim, aspf	Alignment mode: r (relaxed) or s (strict).	r (relaxed) is the default
fo	When to generate failure reports.	1

What "alignment" really means

DMARC passes when SPF or DKIM passes and the passing domain aligns with the From domain. With relaxed alignment, a subdomain of the From domain counts as aligned, so a Return-Path of bounce.example.com aligns with a From of news@example.com. With strict alignment the domains must match exactly. The most common cause of "SPF passes but DMARC fails" is a Return-Path or DKIM domain that belongs to your sending platform instead of to you. Enable a custom Return-Path and your own DKIM signing domain to fix it.

Step 5: Verify that everything works

Check the records in DNS

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Each command should return the record you published. If nothing comes back, the record is on the wrong name or has not propagated yet. Wait for the TTL to expire and test again.

Send a test message and read the headers

1. Send a message from your authenticated domain to a Gmail address you control.
2. Open the message, choose the three-dot menu and select Show original.
3. At the top you will see SPF, DKIM and DMARC with a PASS or FAIL for each.
4. Check that the domain shown next to each PASS matches your From domain.

Roll out DMARC safely: from p=none to p=reject

The goal is p=reject, because that is the only policy that stops others from spoofing your domain. But jumping there blindly can block legitimate mail from tools you forgot about. Move in stages and let the reports guide you.

Stage	Policy	Duration	What to do
1. Monitor	p=none	2 to 4 weeks	Read aggregate reports. List every source sending as your domain and fix or authorise each legitimate one.
2. Partial quarantine	p=quarantine; pct=25	1 to 2 weeks	Failing mail from 25 percent of traffic goes to spam. Watch for complaints about missing mail.
3. Full quarantine	p=quarantine	2 weeks	Raise pct to 100 once reports show only unauthorised sources failing.
4. Reject	p=reject	Ongoing	Move to reject, optionally stepping pct up in stages. Keep reading reports every month.

DMARC aggregate reports arrive as compressed XML files and are not meant to be read by hand. Use a free or paid DMARC report analyser to turn them into a table of sending sources, volumes and pass or fail results.

Gmail, Yahoo and Microsoft requirements for bulk senders

From February 2024 Gmail and Yahoo started enforcing authentication and unsubscribe rules for anyone sending in volume, and Microsoft began applying comparable requirements to Outlook.com consumer mailboxes from May 2025. In summary:

Requirement	All senders	Bulk senders (about 5,000+ messages a day to the provider)
SPF or DKIM	Required	Both required
DMARC record	Recommended	Required, at least p=none, aligned with From
One-click unsubscribe	Not required for transactional mail	Required for marketing and subscribed mail (RFC 8058 headers); honour requests within two days
Spam complaint rate	Keep low	Stay below 0.10 percent and never reach 0.30 percent (Google Postmaster Tools)
Valid forward and reverse DNS, TLS	Required	Required

Providers can change thresholds, so check their current sender guidelines. Links are in the reference list at the end of this guide.

Separate marketing and transactional mail with subdomains

Reputation is tracked per sending domain and IP. If a promotional campaign causes complaints, you do not want password-reset emails to land in spam. The usual pattern is one subdomain per stream:

Stream	Example From address	Why separate
Transactional	noreply@mail.example.com	Must always arrive quickly. Low volume and high engagement keep reputation high.
Marketing	hello@news.example.com	Higher volume and more complaints. Problems stay contained.
Corporate mail	name@example.com	Your employees' mailboxes stay clear of bulk sending risk.

Each subdomain needs its own SPF and DKIM records. A DMARC record at the parent domain protects subdomains by default; add an sp= tag or a separate record at the subdomain if you need a different policy.

Common authentication errors and how to fix them

Symptom	Likely cause	Fix
SPF permerror or "too many DNS lookups"	More than 10 lookups, or a syntax error	Remove unused includes, flatten stable ranges to ip4, move rare senders to a subdomain.
Multiple SPF records found	Two TXT records start with v=spf1	Merge them into one record.
DKIM: no key for signature	Selector name wrong or record not published	Check the selector in the DKIM-Signature header and compare it to your DNS name.
DKIM: body hash did not verify	Message was altered after signing (footers, link rewriting by another system)	Disable the modifying step or move it before signing.
DMARC fail with SPF pass	Return-Path domain does not align with From	Use a custom Return-Path on your own domain.
DMARC fail with DKIM pass	DKIM d= domain does not align with From	Sign with your own domain, not the platform default.
Record not found	Wrong host name, a trailing dot or the domain appended twice by your DNS panel	Many panels add the domain automatically. Enter only the part before it, for example selector1._domainkey.
Records not updating	Old record cached	Wait for the TTL to expire. Lower TTL before planned changes.

Authentication checklist

• One SPF record at the domain root, under 10 lookups, ending in ~all or -all.
• DKIM selector record published, 2048-bit if your DNS host allows it.
• DMARC record at _dmarc with p=none and a working rua address.
• Custom Return-Path and DKIM domain so both align with your From domain.
• Test message shows SPF, DKIM and DMARC as PASS.
• DMARC reports reviewed weekly during rollout.
• Marketing and transactional mail separated by subdomain.
• Calendar reminder to rotate DKIM keys.

Further reading and sources

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)
• RFC 8058: Signaling One-Click Functionality for List Email Headers
• Google: Email sender guidelines
• Yahoo: Sender best practices
• Related guides: Email warm-up guide and SMTP bounce codes explained.