Order queue open · Verified lists delivered within 24–48 hours
SPF, DKIM, and DMARC setup for cold email 2026: exact DNS records, step-by-step verification commands, and troubleshooting for every authentication failure.
James Whitfield
Lead gen agency owner, 50+ campaigns/month · Updated June 24, 2026
Last updated: June 2026 · James Whitfield, Lead gen agency owner, 50+ campaigns/month
TL;DR — 5 things to know before reading
- SPF, DKIM, and DMARC are DNS records that authenticate your sending domain; per Mailgun's SPF, DKIM, and DMARC setup guide, all three are required for full authentication credit — partial authentication (SPF + DKIM without DMARC) produces 15–25% lower inbox placement than full authentication
- DMARC is the record most frequently missing in failed deliverability setups: SPF and DKIM pass at the authentication level, but without DMARC, receiving servers have no enforcement instruction and treat the domain as partially authenticated
- Cold email sending domains must be separate from your primary business domain — authentication failures or blacklistings on a sending domain affect only outreach, not all company email
- Inframail configures SPF, DKIM, and DMARC automatically when provisioning Microsoft 365 inboxes, eliminating the most common manual configuration errors
- After configuration, verify all three records using MXToolbox SPF/DKIM/DMARC lookup tools and Google Postmaster Tools before sending any campaign volume
Running more than 50 campaigns per month, I have diagnosed more inbox placement failures than I can count. In the majority of cases the root cause is not the message, not the sequence timing, and not the contact list. It is missing or misconfigured email authentication. SPF is present, DKIM is present, DMARC is missing. Or SPF is configured for the wrong mail server. Or DKIM is configured but the selector in DNS does not match the selector the sending provider uses to sign. Each of these cases tells Gmail and Outlook that the sending domain cannot be fully authenticated — and a domain that cannot be fully authenticated is treated as a potential spam source.
This guide covers the complete SPF, DKIM, and DMARC setup for cold email sending domains: what each record does at the technical level, the exact DNS records to configure for each, how to verify each record is working correctly, and how to troubleshoot every failure mode. It also covers when to use Inframail to skip manual configuration entirely — which is almost always the right decision for teams setting up multiple sending domains simultaneously.
The authentication layer is the foundation on which everything else in cold email deliverability is built. Instantly handles warmup and sending; Quarvio provides verified contact lists that keep bounce rates under 1%; Aimfox runs LinkedIn outreach in parallel. All of this depends on DNS authentication working correctly first. A single misconfigured record produces inbox placement failures that no other optimisation can overcome.
SPF is a DNS TXT record that specifies which mail servers are authorised to send email on behalf of your domain. When a receiving server gets an email claiming to be from your-domain.com, it performs a DNS lookup for the SPF record at your-domain.com and checks whether the sending server's IP address appears in the authorised list. If the IP is listed, SPF passes. If it is not, SPF fails.
SPF answers the question: "Is this email coming from a server I authorised to send on my behalf?"
SPF failures cause receiving servers to treat the email as potentially spoofed — sent by someone other than the domain owner. This generates a significant spam filter penalty. Gmail and Outlook both use SPF pass/fail as an early-stage filter signal.
SPF limitations: SPF validates the envelope sender (the Return-Path or MAIL FROM address in the SMTP envelope), not the From: header that recipients see. This is why SPF alone is insufficient — SPF can pass even if the visible From: address is different from the envelope sender. DMARC is required to enforce alignment between the envelope sender and the visible From: address.
DKIM is a DNS TXT record (or CNAME record pointing to a TXT record) that contains a public cryptographic key. Your mail server signs every outgoing email with a private key; the cryptographic signature is embedded in the email headers in the DKIM-Signature field. The receiving server performs a DNS lookup for the DKIM public key and uses it to verify the signature.
If the signature is valid, DKIM passes — confirming two things: (1) the email was signed by a server that holds the private key corresponding to the public key in DNS, and (2) the email was not modified in transit (any modification would invalidate the signature).
DKIM answers the question: "Was this email sent by an authorised server, and was it modified after sending?"
DKIM is the most technically complex of the three authentication records because it involves a key pair generated by your sending provider. You must obtain the public key values from your sending provider and publish them in DNS; the sending provider retains the private key and uses it to sign outgoing email.
DKIM selectors: each DKIM record is identified by a selector (a label that appears before ._domainkey. in the DNS host). A domain can have multiple DKIM records with different selectors, allowing multiple signing keys to be in use simultaneously — Microsoft 365 uses selector1 and selector2 for key rotation.
DMARC is a DNS TXT record that builds on SPF and DKIM by adding two critical functions:
1. Alignment enforcement: DMARC requires the From: header domain (the domain recipients see) to align with either the SPF envelope sender domain or the DKIM signing domain. This closes the gap that SPF alone leaves open: without DMARC alignment, an email could pass SPF with a different sender domain while showing a spoofed From: address to the recipient.
2. Policy instruction: DMARC tells receiving servers what to do with emails that fail the alignment check: none (take no action, just report), quarantine (send to spam), or reject (block the email entirely). Without a DMARC record, receiving servers have no instruction from you and make their own filtering decisions when SPF or DKIM fails.
3. Aggregate reporting: DMARC specifies a reporting address (rua=) where receiving servers send aggregate reports about authentication outcomes for email from your domain. These reports show you which sources are sending email claiming to be from your domain, and whether authentication is passing or failing.
DMARC answers the question: "What should receiving servers do with emails from my domain that fail authentication, and who should be notified?"
The three records work as a system, not independently. Understanding how they interact explains why partial authentication produces lower inbox placement than full authentication.
SPF validates the sending server but not the From: header domain. DKIM validates message integrity but not the From: header domain. DMARC validates that the From: header domain aligns with the authenticated sender — and tells receiving servers what to do when it does not.
Consider the failure mode when DMARC is missing: an attacker sends email claiming to be from your-domain.com through a legitimate mail server. SPF passes (legitimate server is authorised). DKIM passes (email was not modified). But without DMARC, there is no check to confirm the visible From: domain matches the authenticated domains. The spoofed email passes authentication.
Per Mailgun's SPF, DKIM, and DMARC setup guide, Gmail and Microsoft score domain authentication as a composite of all three records. A domain with SPF and DKIM but no DMARC receives partial authentication credit. A domain with all three in alignment receives full authentication credit — the highest possible inbox placement score from the authentication layer.
Before configuring authentication records, you need:
Access to your domain's DNS settings: through your registrar's control panel (Namecheap, Cloudflare, GoDaddy). Changes take 15 minutes to a few hours to propagate. Full global propagation can take up to 48 hours.
Dedicated sending domains, not your primary domain: never configure SPF for cold email sending on your primary business domain. Use domains registered specifically for cold outreach (see Step 1). If you are using Inframail, domains and authentication are provisioned automatically.
Access to your sending provider's admin panel: to obtain DKIM key values. For Microsoft 365 (Inframail), this is the Microsoft 365 admin centre. For Google Workspace, this is the Google Admin console.
An email address to receive DMARC reports: any address you can monitor. Reports arrive as XML data files attached to emails. You can use a dedicated address like dmarc-reports@your-sending-domain.com.
Do not configure SPF, DKIM, and DMARC for cold email sending on your primary business domain. Use dedicated domains purchased specifically for cold outreach.
Why dedicated domains are required:
-all SPF, p=reject DMARC) without affecting your primary domain's configurationNaming dedicated sending domains: choose variations of your primary brand rather than unrelated strings:
companyname-outreach.comhello-companyname.comgetcompanyname.comcompanyname-hq.comAvoid excessive hyphens, numbers, or generic terms (mailsender123.com) that do not map to a recognisable brand — these signal suspicious intent to spam filters.
Domain registration timing: register sending domains 30–45 days before campaign start and begin inbox warmup immediately. Domain age is a factor in spam filter trust scoring — a 45-day-old domain with 45 days of warmup history starts campaigns with significantly more accumulated reputation than a 2-day-old domain.
Inframail as an alternative to manual setup: Inframail provisions Microsoft 365 inboxes with dedicated domains and configures SPF, DKIM, and DMARC automatically as part of the inbox provisioning process. For teams setting up 3–10 sending domains simultaneously, Inframail's automated setup eliminates manual configuration errors and reduces setup time from hours to minutes. If you are using Inframail, the manual Steps 2–4 below are handled automatically.
Access your domain's DNS settings through your registrar.
SPF record format:
Type: TXT
Host: @ (root domain)
Value: v=spf1 include:[mail-provider-spf-include] -all
TTL: 3600
SPF values by sending provider:
| Provider | SPF include value |
|---|---|
| Microsoft 365 (Inframail) | include:spf.protection.outlook.com |
| Google Workspace | include:_spf.google.com |
| SendGrid | include:sendgrid.net |
Full SPF record for Microsoft 365 / Inframail:
v=spf1 include:spf.protection.outlook.com -all
Understanding the SPF mechanisms:
The -all at the end of the SPF record is the catch-all mechanism. It specifies what to do with email from servers not listed in the record:
-all (hard fail): reject email from unlisted servers — use this for dedicated cold email sending domains~all (soft fail): mark as suspicious but deliver — less strict, do not use for cold email domains+all (pass all): allow all senders — never use this, it defeats the purpose of SPF entirelySPF sub-steps:
@ and the value aboveCritical SPF rules:
@), not a subdomainBenchmark: single SPF TXT record at @ with -all hard fail mechanism. No duplicate SPF records.
Failure mode — multiple SPF records: the most common SPF error. Adding a second SPF TXT record alongside an existing one invalidates both. The receiving server encounters two SPF records and cannot determine which is authoritative. Result: permanent SPF failure for all sends.
Failure mode — soft fail ~all: using ~all instead of -all means SPF fails softly, which is treated as partial authentication by receiving servers. Cold email domains should use hard fail.
DKIM configuration requires obtaining a key pair from your sending provider and publishing the public key in DNS. Your sending provider generates and retains the private key; you publish the public key.
admin.microsoft.comType: CNAME
Host: selector1._domainkey
Value: selector1-[domain-hash]._domainkey.[your-tenant].onmicrosoft.com
Type: CNAME
Host: selector2._domainkey
Value: selector2-[domain-hash]._domainkey.[your-tenant].onmicrosoft.com
The [domain-hash] and [your-tenant] portions are unique to your domain and Microsoft 365 tenant. Copy the exact values provided by the admin centre.
Note: if you are using Inframail, DKIM is configured automatically during inbox provisioning. You do not need to complete Steps 1–8 manually.
admin.google.comType: TXT
Host: google._domainkey (the selector is "google" by default)
Value: v=DKIM1; k=rsa; p=[long-public-key-string]
TTL: 3600
Most sending providers follow one of two formats:
Your sending provider's admin interface or documentation will specify which format to use and provide the exact record values. Never guess or construct these values — they must be obtained from the provider.
DKIM sub-steps regardless of provider:
Benchmark: DKIM-Signature present in outgoing email headers, DKIM verification passing in MXToolbox DKIM lookup, 2048-bit key minimum.
Failure mode — selector mismatch: the selector in the DNS record (selector1._domainkey) must exactly match the s= tag in the DKIM-Signature header of outgoing emails. If your provider signs with selector1 but your DNS record is only for selector2, DKIM fails. Verify the selector value by inspecting the DKIM-Signature header in a sent test email.
Failure mode — CNAME not propagated: CNAME records for DKIM can take longer to propagate than TXT records in some DNS configurations. If DKIM is still failing 2 hours after adding the CNAME records, check whether the CNAME is resolving correctly using a DNS lookup tool.
DMARC is a single TXT record at the _dmarc subdomain of your sending domain. This is one of the most common configuration mistakes — the record must be at _dmarc.your-domain.com, not at @ or anywhere else.
DMARC policy progression:
| Phase | Policy value | When to use | What it does |
|---|---|---|---|
| Initial | p=none | First 2 weeks after setup | Monitoring only, no enforcement |
| Intermediate | p=quarantine | Weeks 3–4, after confirming no failures | Routes failed emails to spam |
| Final | p=reject | After 4 weeks, once stable | Blocks failed emails entirely |
Step 4a: Initial DMARC record (monitoring mode):
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@your-sending-domain.com; pct=100
TTL: 3600
Parameters explained:
p=none: take no action on failures, just reportrua=mailto:...: send aggregate reports to this email addresspct=100: apply the policy to 100% of emails (not a sample)Step 4b: After 2 weeks — review DMARC aggregate reports
The aggregate reports sent to your rua= address show all sources that sent email claiming to be from your domain and whether SPF and DKIM passed or failed for each. Review these reports to confirm:
If the reports show only expected sources with all passes, proceed to Step 4c. If they show unexpected sources or failures, investigate before increasing enforcement.
Step 4c: Move to quarantine
Update the DMARC record to p=quarantine:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-sending-domain.com; pct=100
This routes emails that fail authentication to the spam folder rather than blocking them. Run this for one more week while monitoring for any legitimate email being quarantined.
Step 4d: Move to reject (full enforcement)
After confirming no legitimate email failures, update the DMARC record to p=reject with strict alignment:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-sending-domain.com; pct=100; adkim=s; aspf=s
Additional parameters:
p=reject: block emails that fail authentication entirelyadkim=s: strict DKIM alignment — the DKIM d= domain must exactly match the From: domainaspf=s: strict SPF alignment — the SPF envelope sender domain must exactly match the From: domainFor dedicated cold email sending domains where you control all sending (no external services sending on your behalf), strict alignment is correct and safe.
Benchmark: DMARC at p=reject with adkim=s; aspf=s within 30 days of domain setup. DMARC aggregate reports showing 100% pass rate for all legitimate sends.
Failure mode — DMARC at wrong subdomain: adding the DMARC record at @ instead of _dmarc. Receiving servers look for DMARC specifically at _dmarc.your-domain.com. If you add it at @, it will not be found and DMARC will be treated as absent.
Failure mode — DMARC never progressed from p=none: many operators set up DMARC at p=none and never update it. p=none provides partial authentication credit; p=reject provides full authentication credit. Not progressing to p=reject after 30 days means leaving 15–25% inbox placement on the table permanently.
After allowing 15–30 minutes for DNS propagation after adding each record, verify each one is correctly configured.
SPF verification using MXToolbox:
-all mechanism should appear at the endSPF verification using email headers:
Send a test email from the sending inbox to a Gmail address. In Gmail, open the email and click the three-dot menu → "Show original." In the raw email headers, look for:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of user@your-sending-domain.com designates [IP] as permitted sender)
spf=pass confirms SPF is working. spf=fail or spf=softfail indicates SPF is configured incorrectly.
Sub-steps for SPF verification:
spf=pass in Authentication-ResultsDKIM verification using MXToolbox:
selector1)DKIM verification using email headers:
In the raw email headers of a test email sent to Gmail:
Authentication-Results: mx.google.com;
dkim=pass header.i=@your-sending-domain.com header.s=selector1
dkim=pass confirms DKIM is working. The header.i= value should show your sending domain, not a third-party platform domain. If it shows header.i=@thirdpartyplatform.com, your sending platform is signing DKIM for their domain rather than yours — this will cause DMARC alignment failure even though DKIM authentication passes.
Sub-steps for DKIM verification:
selector1selector2 as well if using Microsoft 365 (both selectors should be active)dkim=pass with header.i=@your-sending-domain.comDMARC verification using MXToolbox:
_dmarc.your-domain.comp=) should show your current policy valuerua=) should show your configured addressadkim=, aspf=) should show s (strict) for dedicated sending domainsDMARC verification using email headers:
In the raw email headers of a test email:
Authentication-Results: mx.google.com;
dmarc=pass (p=reject dis=none) header.from=your-sending-domain.com
dmarc=pass confirms DMARC is passing. The (p=...) shows which policy is in effect. header.from= should show your sending domain.
Checking DMARC alignment specifically:
DMARC alignment failure is distinct from DMARC authentication failure. Alignment failure means SPF and DKIM individually pass but the From: header domain does not match the authenticated domains. Check for:
d= tag (visible in the DKIM-Signature header) should match your sending domain exactly when using adkim=s strict alignmentReturn-Path header) should match your sending domain exactly when using aspf=s strict alignmentIf alignment is failing, the most common cause is the sending platform signing DKIM for their own domain rather than yours. Verify your sending provider configuration.
DNS configuration is a one-time setup. Ongoing monitoring is a continuous requirement.
Setting up Google Postmaster Tools:
Metrics to monitor weekly:
Benchmark: all sending domains configured in Postmaster Tools. Domain reputation "High" for all active sending domains. Authentication pass rate 100%.
Authentication configuration does not require ongoing changes once set correctly. However, certain events can trigger authentication failures that require investigation.
Trigger events that may require authentication updates:
Regular authentication health checks:
DMARC aggregate report interpretation: when reviewing DMARC reports, look for:
| Record | DNS type | Host | Value format | Where to get values |
|---|---|---|---|---|
| SPF | TXT | @ | v=spf1 include:[provider-include] -all | Sending provider documentation |
| DKIM (M365) | CNAME | selector1._domainkey | selector1-[hash]._domainkey.[tenant].onmicrosoft.com | Microsoft 365 admin centre |
| DKIM (M365) | CNAME | selector2._domainkey | selector2-[hash]._domainkey.[tenant].onmicrosoft.com | Microsoft 365 admin centre |
| DKIM (G Suite) | TXT | google._domainkey | v=DKIM1; k=rsa; p=[public-key] | Google Admin console |
| DMARC (initial) | TXT | _dmarc | v=DMARC1; p=none; rua=mailto:[email]; pct=100 | Configured manually |
| DMARC (final) | TXT | _dmarc | v=DMARC1; p=reject; rua=mailto:[email]; pct=100; adkim=s; aspf=s | Configured manually |
| Verification check | Tool | What to look for |
|---|---|---|
| SPF lookup | MXToolbox SPF Lookup | Record found, no errors, -all present |
| SPF in headers | Gmail email headers | spf=pass in Authentication-Results |
| DKIM lookup | MXToolbox DKIM Lookup | Record found, RSA, 2048-bit |
| DKIM in headers | Gmail email headers | dkim=pass, header.i=@your-domain.com |
| DMARC lookup | MXToolbox DMARC Lookup | Record at _dmarc, correct policy |
| DMARC in headers | Gmail email headers | dmarc=pass in Authentication-Results |
| Domain reputation | Google Postmaster Tools | "High" reputation tier |
| Authentication pass rate | Google Postmaster Tools | 100% pass rate |
Manual DKIM configuration for multiple sending domains across multiple registrars is error-prone. A single character error in a CNAME value, a DMARC record added at @ instead of _dmarc, or a duplicate SPF record all cause silent authentication failures that are difficult to diagnose without systematic verification.
Inframail provisions Microsoft 365 inboxes with dedicated domains and configures SPF, DKIM, and DMARC automatically. For teams setting up 3–10 sending domains, the time savings and error elimination justify the use of a managed infrastructure service over manual configuration. Each inbox provisioned in Inframail arrives with authentication fully configured and verified.
Many operators set DMARC to p=none for monitoring and never update it. p=none provides partial authentication credit; p=reject provides full authentication credit. The 30-day progression from p=none to p=reject (via p=quarantine) is standard practice for dedicated sending domains where you control all sending. Do not let DMARC remain at p=none longer than 30 days.
Microsoft 365 uses two DKIM selectors (selector1 and selector2) to enable key rotation without service interruption. Periodically rotating DKIM keys (every 12 months) is a security best practice that also ensures your DKIM signing remains on current key standards. Microsoft 365 handles key rotation automatically when both CNAME records are in DNS and DKIM signing is enabled.
DMARC aggregate reports reveal every source sending email claiming to be from your domain. If reports show IP addresses you do not recognise, your domain is being spoofed — third parties are sending email with your domain in the From: header. Moving DMARC to p=reject blocks this spoofing and protects your domain's reputation from being damaged by third-party spam operations using your domain name.
Before launching any new campaign from a domain, run a three-step authentication verification:
_dmarc, policy is p=reject, alignment is strictThis five-minute check catches authentication failures caused by DNS changes at the registrar level, sending provider infrastructure updates, or accidental record deletions.
Problem 1: SPF failing on a domain that has correct SPF syntax
Most likely cause: duplicate SPF records. DNS allows only one SPF TXT record per domain. If your domain has two TXT records starting with v=spf1, both are invalidated. Log in to your registrar's DNS management interface, find all TXT records at @, and verify there is only one SPF record. If there are two, delete both and create a single record that merges all necessary includes.
Verify by running MXToolbox SPF Lookup and checking whether the error message is "Multiple SPF records found" — if yes, this is the cause.
Problem 2: DKIM failing despite correct CNAME records in DNS
Most likely cause: CNAME not yet propagated, or DKIM signing not enabled in the sending provider's admin panel. The CNAME records must be added to DNS and the DKIM signing must be separately enabled in the admin centre — they are two independent steps. Check that DKIM signing is enabled under the specific domain in the Microsoft 365 admin centre (or equivalent for other providers). Allow 30–60 minutes after enabling and test again.
If still failing after 60 minutes, use a DNS propagation checker to confirm the CNAME records are resolving globally. CNAME records sometimes take longer to propagate than TXT records.
Problem 3: DMARC failing despite SPF and DKIM individually passing
This is an alignment failure, not an authentication failure. DMARC passes only when the From: header domain aligns with the authenticated sender domains. Check the d= tag in the DKIM-Signature header of a sent email (visible in Gmail's "Show original" view). If it shows @thirdpartyplatform.com instead of @your-sending-domain.com, your sending platform is signing DKIM for their own domain.
To fix: configure your sending platform to sign DKIM for your specific sending domain. In Instantly, this is done by adding the inbox as a verified custom domain. In Microsoft 365 (Inframail), DKIM is automatically signed for the specific sending domain of each inbox.
Problem 4: DMARC record not found by MXToolbox
Most likely cause: DMARC record was added at @ instead of _dmarc. The DMARC record must be at the subdomain _dmarc.your-domain.com, not at the root domain @. Log in to your registrar's DNS and check what host the DMARC TXT record is at. If it is at @, delete it and re-add it with host _dmarc (not _dmarc.your-domain.com — just _dmarc, and the registrar appends the domain automatically).
Problem 5: SPF record has too many DNS lookups
SPF processing is limited to 10 DNS lookups during evaluation. Complex SPF records with many include: directives can exceed this limit, causing SPF to fail with a "PermError: too many DNS lookups" result. This often occurs when multiple services each add their own SPF includes to your record.
To fix: audit your SPF record and flatten it. Replace nested include chains with direct IP address entries where possible. For example, instead of include:serviceprovider.com which itself includes three more records, look up the actual IP addresses in the service provider's SPF record and include them directly as ip4: entries.
Problem 6: Authentication passing but domain reputation still declining
Authentication is necessary but not sufficient for inbox placement. If SPF, DKIM, and DMARC are all passing but domain reputation in Postmaster Tools is declining, the cause is one of the reputation layer factors: spam complaint rate above 0.1%, bounce rate above 3%, or sending volume above 50 per inbox per day for the reputation level of that inbox. Check Postmaster Tools for spam rate trends and check campaign analytics for bounce rate. Address whichever metric is elevated.
Problem 7: DKIM working on Gmail but failing on Outlook
Outlook validates DKIM differently from Gmail in certain cases. The most common cause of DKIM passing at Gmail but failing at Outlook is a mismatch between the DKIM selector in DNS and the selector the sending platform uses for signing. Outlook may be checking a different selector than the one that is configured. Verify the selector being used to sign emails from the DKIM-Signature header (s= tag) and confirm it matches the selector you configured in DNS. Also verify the DKIM key length is 2048 bits — 1024-bit keys are increasingly rejected by Outlook.
Problem 8: Authentication fails after changing to a new email provider
When switching sending providers, the old DKIM keys become invalid because the new provider uses different private keys for signing. You must: (1) obtain new DKIM CNAME or TXT records from the new provider; (2) add the new DKIM records to DNS; (3) enable DKIM signing for the domain in the new provider's admin panel; (4) optionally remove the old DKIM records (they are harmless but add DNS clutter).
Also update the SPF record to include the new provider's SPF include value and remove the old provider's include if it is no longer relevant. After any provider change, run the full five-step authentication verification routine (Steps 5–7) to confirm all three records are passing with the new provider.
"I had SPF and DKIM set up correctly for six months. Still landing in spam for Gmail addresses. Added DMARC with
p=reject, inbox placement went from 55% to 91% within two weeks. DMARC was the missing piece nobody told me about when I initially set up the infrastructure."— Verified G2 reviewer, director of outbound, B2B technology company, Inframail reviews on G2
"Tried to configure authentication manually on three domains over two weeks. Two had SPF issues I could not diagnose, one had a DKIM selector mismatch. Switched to Inframail and all three domains had full authentication in 30 minutes. The time cost of manual setup was not worth it at the scale we were running."
— Verified G2 reviewer, lead gen consultant, outbound agency, Instantly reviews on G2
"We had DMARC at
p=nonefor 11 months because nobody knew it needed to be updated. Our inbox placement at Gmail was consistently around 65%. Moved top=reject, and within three weeks it climbed above 85% and has stayed there. The progression fromp=nonetop=rejectis not optional —p=noneis just the starting point, not the destination."— Verified G2 reviewer, operations director, outbound sales team, B2B SaaS company, Inframail reviews on G2
Per Mailgun's SPF, DKIM, and DMARC setup guide, domains with full SPF + DKIM + DMARC alignment consistently achieve 15–25% higher inbox placement rates compared to domains with partial authentication — making full authentication the most impactful single technical decision in cold email deliverability setup.
| Need | Tool | Notes |
|---|---|---|
| Verified B2B contacts | Quarvio | One-time purchase, no subscription |
| Email inboxes | Inframail | Microsoft 365 inboxes, auto DNS |
| Cold email sending | Instantly | Sequences, warm-up, reply tracking |
| LinkedIn outreach | Aimfox | Connection campaigns, Unibox |
Do I need SPF, DKIM, and DMARC for every sending domain?
Yes. Authentication records must be configured for each dedicated sending domain, not just your primary domain. If you have five sending domains, each one needs its own SPF record, its own DKIM key pair, and its own DMARC record at _dmarc.[domain]. Inframail handles this automatically for every inbox provisioned, eliminating the per-domain configuration overhead.
What happens if I only set up SPF and DKIM but not DMARC?
Without DMARC, receiving servers have no instruction for handling authentication failures and no enforcement of From: header alignment. Gmail and Microsoft treat DMARC-configured domains as more trustworthy than domains without it. Per Mailgun's SPF, DKIM, and DMARC setup guide, SPF + DKIM without DMARC produces noticeably lower inbox placement than full authentication. Add DMARC at p=none immediately and progress to p=reject within 30 days.
How long does it take for DNS records to propagate?
With a TTL of 3600 (1 hour), records typically propagate globally within 1–4 hours. Some records take up to 48 hours for full global propagation. For practical purposes, test authentication 30 minutes after adding records and verify again after 2 hours before drawing conclusions about whether propagation is complete. Do not start campaign sends until authentication is confirmed passing.
What is DMARC alignment and why does it fail even when SPF and DKIM pass?
DMARC alignment checks whether the domain in the email From: header matches the domain used for SPF and/or DKIM authentication. With adkim=s (strict DKIM alignment), the DKIM signature's d= tag must exactly match the From: domain. With aspf=s (strict SPF alignment), the envelope sender domain (Return-Path) must exactly match the From: domain. Alignment failure occurs most commonly when a sending platform signs DKIM for their own shared domain rather than your sending domain.
Is a 2048-bit DKIM key required?
2048-bit is the minimum recommended key length. 1024-bit keys are considered cryptographically weak and are increasingly rejected by Outlook. Some older sending provider configurations still generate 1024-bit keys by default. When configuring DKIM, verify the key length in MXToolbox DKIM Lookup. If it shows 1024-bit, contact your sending provider to generate a new 2048-bit key.
What does the DMARC rua= reporting address receive?
The rua= address receives aggregate DMARC reports: XML files (typically delivered as email attachments) that summarise authentication outcomes for all email from your domain over a 24-hour period. Each report shows the sending IP addresses, SPF and DKIM pass/fail results, and DMARC disposition. These reports are essential for diagnosing alignment failures and detecting domain spoofing. Set the rua= address to an inbox you check at least weekly.
How do I configure DMARC if my domain uses multiple sending providers?
Each sending provider that sends email on behalf of your domain must be included in your SPF record. Each provider must also have its own DKIM configuration for your domain (separate selectors). DMARC then evaluates alignment based on whichever of SPF or DKIM passes and aligns. If one provider passes DKIM alignment and another passes SPF alignment, DMARC passes in both cases — it requires alignment with at least one of the two authentication methods, not both.
What is the difference between DMARC adkim=s (strict) and adkim=r (relaxed) alignment?
Strict alignment (adkim=s) requires the DKIM d= domain to exactly match the From: domain. Relaxed alignment (adkim=r) allows the DKIM d= domain to be a parent domain of the From: domain. For example, with relaxed alignment, DKIM signed for mail.sending-domain.com aligns with From: user@sending-domain.com. For dedicated cold email sending domains where you control all sending and sign DKIM for your exact sending domain, strict alignment is the correct choice and provides a stronger authentication signal.
Can I use the same DKIM key across multiple sending domains?
No. Each sending domain requires its own DKIM key pair. The private key signs emails sent from that specific domain, and the public key is published in DNS for that specific domain. Sharing keys across domains is not technically supported — each DKIM record is associated with one domain and one selector combination.
How do I know if my DMARC is configured correctly without waiting for reports?
Use MXToolbox DMARC Lookup and the full email headers in Gmail. MXToolbox shows the current DMARC record content and any syntax errors. Gmail email headers show whether DMARC is passing or failing for individual emails in real time. Send a test email from each sending inbox to a Gmail address and check for dmarc=pass in the Authentication-Results header — this is the definitive confirmation that DMARC is working correctly.
What should I do if DMARC aggregate reports show an unrecognised IP sending email from my domain?
This indicates your domain is being spoofed — a third party is using your domain in the From: header to send email without your authorisation. Move DMARC to p=reject immediately if you are not already there. This blocks spoofed emails at the receiving server level and protects your domain's reputation from being damaged by third-party spam operations using your domain name. If you are already at p=reject and still see spoofed emails in the reports, the spoofing is being blocked (this is the expected behaviour) but the spoofing attempts are still occurring.
Authentication sets the floor. Contact quality sets the ceiling.
Fully authenticated sending domains land in inboxes. Verified contact lists keep bounce rates low and spam complaint rates under control. Quarvio delivers pre-verified B2B contact lists that pair with proper authentication infrastructure — one-time purchase, credits valid for 12 months, no subscription. Lists start at $129 for 5,000 contacts, $199 for 10,000, $399 for 25,000, and $699 for 50,000.