Essential DNS Records for Email Marketing Explained (2026)
If you are sending any form of bulk email—whether it is an opt-in newsletter to 100,000 subscribers or cold outreach to 50 targeted prospects—your technical foundation dictates your success.
In 2026, Google, Yahoo, and Microsoft do not just "prefer" authenticated emails; they demand them. If your DNS records are not configured correctly, your emails will be hard-rejected at the server level, never even making it to the spam folder.
This guide breaks down the three essential DNS records you must configure before sending a single campaign, explaining the technical jargon in plain English.
1. SPF: The Digital Passport
SPF stands for Sender Policy Framework.
When you send an email from maya@yourcompany.com, the receiving server (like Gmail) wants to know if the server that actually dispatched the email is authorized to send on behalf of yourcompany.com.
SPF is a public list published in your domain's DNS that explicitly states which IP addresses and services (like Google Workspace, Mailchimp, or SendGrid) have permission to send emails for you.
How SPF Works
If a spammer tries to spoof your email address and sends a phishing email to someone, the receiving server will check the spammer's IP address against your SPF record. Because the spammer's IP is not on your list, the email is flagged and rejected.
Example Google Workspace SPF: v=spf1 include:_spf.google.com ~all
Example Microsoft 365 SPF: v=spf1 include:spf.protection.outlook.com ~all (This tells receivers: "Only Google is authorized to send emails for me. If the email comes from anywhere else, treat it softly (~) as a fail.")
Critical Mistake to Avoid: You can only have one SPF record per domain. If you use multiple services (e.g., Google Workspace AND ActiveCampaign), you must merge them into a single string: v=spf1 include:_spf.google.com include:emsd1.com ~all. Having two SPF TXT records will cause a hard fail.2. DKIM: The Wax Seal
DKIM stands for DomainKeys Identified Mail.
If SPF proves who sent the email, DKIM proves the email wasn't tampered with in transit. It acts like a digital wax seal on a physical letter.
How DKIM Works
When you send an email, your sending server uses a private cryptographic key to generate a unique digital signature, attaching it invisibly to the email header.
Your domain's DNS publishes the corresponding public key. When the receiving server gets your email, it uses that public key to verify the signature. If the signature matches, the seal is unbroken. If a malicious actor intercepted and altered the email content along the way, the signature breaks, and the email is rejected.
Example Google Workspace DKIM:
- Host Name:
google._domainkey - TXT Value:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3D...
Example Microsoft 365 DKIM (Usually CNAMEs):
- Host Name 1:
selector1._domainkey->selector1-yourcompany-com._domainkey.tenant.onmicrosoft.com - Host Name 2:
selector2._domainkey->selector2-yourcompany-com._domainkey.tenant.onmicrosoft.com
Unlike SPF, you can and should have multiple DKIM records if you use multiple sending platforms.
3. DMARC: The Bouncer at the Door
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.
SPF and DKIM are fantastic, but what happens if an email fails those checks? Historically, the receiving server just had to guess what you wanted them to do with it. DMARC tells them exactly what to do.
It is a policy that you publish in your DNS instructing inbox providers on how to handle emails that claim to be from you but fail authentication.
The 3 DMARC Policies:
-
p=none(Monitoring Mode): "If it fails, just deliver it normally, but send me a report." (Useful for initial setup). -
p=quarantine(Protection Mode): "If it fails, send it straight to the spam/junk folder." -
p=reject(Lockdown Mode): "If it fails, delete it immediately. Do not even deliver it to spam."
In 2026, Google and Yahoo require bulk senders to have a DMARC policy in place.
Example DMARC Record: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.com;
A Note on Alignment (`aspf` and `adkim`)
DMARC checks if the domain in your "From" address exactly aligns with the domain authenticated by SPF and DKIM. You can set this alignment to be Strict (s) or Relaxed (r).
- Relaxed (
r): (Default) Allows a subdomain (likemail.yourcompany.com) to align with the root domain (yourcompany.com). - Strict (
s): The domains must be a 100% exact character match. Relaxed is highly recommended for cold outreach.
Quick Comparison
Here is a quick summary of the three essential protocols:
- SPF (Sender Policy Framework): Proves if the server is authorized. Acts like a Passport. Without DMARC, failure leads to soft flagging.
- DKIM (DomainKeys Identified Mail): Proves the email wasn't altered. Acts like a Wax Seal. Failure damages your reputation heavily.
- DMARC (Domain-based Message Authentication): Dictates what to do if SPF or DKIM fail. Acts like a bouncer. An essential policy requirement for modern sending.
Technical Auditing Checklist
You should never send an email until you have verified these records. Follow this simple auditing process:
- Setup Complete: Ensure you have added the TXT records to your DNS provider.
- Use MXToolbox: Go to MXToolbox.com and use the "SuperTool".
- Check SPF: If it fails, update your TXT record.
- Check DKIM: If it fails, generate a new key in your admin console.
- Check DMARC: If it fails, publish a basic DMARC monitoring policy.
- Wait for TTL (Time to Live): DNS changes are not instant. TTL is the time it takes for internet servers worldwide to refresh their cache of your records. If your TTL is 3600, you must wait 3600 seconds (1 hour) before testing.
- All Pass: You are ready to start warming up your domain!
Simplifying the Complex
Configuring DNS correctly is not optional, but it is highly technical. A single typo in a DMARC record can cause your entire company's email to silently fail.
If your team is managing multiple domains and sending identities, modern delivery platforms are essential. Mailshrine drastically simplifies this infrastructure.
When you connect a domain, Mailshrine automatically scans your DNS, highlights missing SPF/DKIM/DMARC records, provides the exact values you need to copy-paste into your registrar, and continuously monitors your authentication health so a broken record never derails a live campaign.
Citations & References
- Reference: dmarc.org - Domain-based Message Authentication
- Reference: RFC 7208: Sender Policy Framework (SPF)
Written by Maya S., Independent Email Infrastructure Consultant. Maya advises global marketing teams on DNS architecture, security compliance, and inbox deliverability protocols.




