How to Use Adaptix for AI-Driven Lead Generation

<!DOCTYPE html>

<head>

<title>SPF, DKIM, and DMARC — Adaptix.ai Blog</title>

<style>

:root {

–teal: #1ac8a0;

–navy: #0d1f2d;

–ink: #1e2d3d;

–muted: #64788a;

–bg: #f9fafb;

–card: #ffffff;

–border: #e4eaf0;

–code-bg: #0d1f2d;

–code-text: #7dd3b0;

}

* { box-sizing: border-box; margin: 0; padding: 0; }

body {

font-family: ‘DM Sans’, sans-serif;

background: var(–bg);

color: var(–ink);

line-height: 1.75;

font-size: 17px;

}

/* ── top bar ── */

.topbar {

background: var(–navy);

padding: 12px 32px;

display: flex;

align-items: center;

justify-content: space-between;

}

.topbar-brand {

font-family: ‘DM Sans’, sans-serif;

font-weight: 600;

font-size: 15px;

color: var(–teal);

letter-spacing: .04em;

}

.copy-btn {

background: var(–teal);

color: var(–navy);

border: none;

border-radius: 6px;

padding: 8px 20px;

font-family: ‘DM Sans’, sans-serif;

font-weight: 600;

font-size: 13px;

cursor: pointer;

letter-spacing: .02em;

transition: opacity .15s;

}

.copy-btn:hover { opacity: .85; }

.copy-btn.copied { background: #fff; color: var(–navy); }

/* ── layout ── */

.wrapper {

max-width: 780px;

margin: 0 auto;

padding: 56px 32px 96px;

}

/* ── post header ── */

.post-meta {

font-size: 13px;

font-weight: 500;

color: var(–teal);

letter-spacing: .08em;

text-transform: uppercase;

margin-bottom: 20px;

}

.post-title {

font-family: ‘Lora’, serif;

font-size: clamp(28px, 4vw, 44px);

font-weight: 700;

color: var(–navy);

line-height: 1.2;

margin-bottom: 24px;

}

.post-byline {

font-size: 14px;

color: var(–muted);

margin-bottom: 48px;

padding-bottom: 32px;

border-bottom: 2px solid var(–border);

}

.post-byline strong { color: var(–ink); }

/* ── body copy ── */

.post-body p {

margin-bottom: 22px;

font-size: 17px;

color: var(–ink);

}

h2 {

font-family: ‘Lora’, serif;

font-size: clamp(22px, 3vw, 30px);

font-weight: 700;

color: var(–navy);

margin: 56px 0 18px;

line-height: 1.25;

}

h3 {

font-family: ‘DM Sans’, sans-serif;

font-size: 19px;

font-weight: 600;

color: var(–teal);

margin: 36px 0 14px;

}

/* ── callout ── */

.callout {

border-left: 4px solid var(–teal);

background: #edf9f5;

border-radius: 0 8px 8px 0;

padding: 18px 22px;

margin: 28px 0;

font-size: 15.5px;

color: #1a3a30;

}

.callout strong { color: var(–navy); }

/* ── code block ── */

.code-block {

background: var(–code-bg);

border-radius: 8px;

padding: 20px 24px;

margin: 24px 0;

overflow-x: auto;

}

.code-block code {

font-family: ‘Courier New’, monospace;

font-size: 14px;

color: var(–code-text);

line-height: 1.7;

display: block;

white-space: pre;

}

.code-block .comment { color: #4a7a63; }

/* ── lists ── */

ul, ol {

padding-left: 24px;

margin: 0 0 22px;

}

li {

margin-bottom: 10px;

font-size: 17px;

}

/* ── table ── */

.table-wrap { overflow-x: auto; margin: 28px 0; }

table {

width: 100%;

border-collapse: collapse;

font-size: 15px;

}

th {

background: var(–navy);

color: #fff;

font-weight: 600;

text-align: left;

padding: 12px 16px;

font-size: 13px;

letter-spacing: .04em;

}

td {

padding: 11px 16px;

border-bottom: 1px solid var(–border);

vertical-align: top;

}

tr:nth-child(even) td { background: #f4f7fa; }

td:first-child { font-weight: 600; color: var(–navy); }

/* ── FAQ ── */

.faq-item {

border-bottom: 1px solid var(–border);

padding: 28px 0;

}

.faq-item:last-child { border-bottom: none; }

.faq-q {

font-weight: 600;

font-size: 17px;

color: var(–navy);

margin-bottom: 10px;

}

.faq-q::before {

content: “Q “;

color: var(–teal);

font-weight: 700;

}

.faq-a {

font-size: 16.5px;

color: #3a4e5e;

line-height: 1.75;

}

/* ── section divider ── */

hr {

border: none;

border-top: 2px solid var(–border);

margin: 48px 0;

}

/* ── footer ── */

.post-footer {

margin-top: 64px;

padding-top: 32px;

border-top: 2px solid var(–border);

text-align: center;

font-size: 14px;

color: var(–muted);

}

.post-footer strong { color: var(–teal); }

/* ── hidden WP content ── */

#wp-content { display: none; }

</style>

</head>

<body>

<span class=”topbar-brand”>ADAPTIX.AI — Blog Preview</span>

<button class=”copy-btn” onclick=”copyWP(this)”>⎘ Copy WordPress HTML</button>

</div>

<!– ═══════════════ POST HEADER ═══════════════ –>

<div class=”post-meta”>Email Deliverability · Adaptix.ai</div>

<h1 class=”post-title”>SPF, DKIM, and DMARC: What They Are, How They Work, and Why Your Emails Depend on All Three</h1>

<div class=”post-byline”>By <strong>Joe</strong>  ·  Adaptix.ai  ·  ~11 min read</div>

<!– ═══════════════ BODY ═══════════════ –>

<p>If your emails are landing in spam folders and you can’t figure out why, there’s a decent chance the problem has nothing to do with your subject lines or your sending frequency. It has to do with three acronyms that most marketers glaze over the first time they see them: SPF, DKIM, and DMARC.</p>

<p>I get it — DNS records aren’t exactly exciting. But once you understand what these three protocols actually do, they stop being intimidating alphabet soup and start looking like the straightforward infrastructure settings they are. More importantly, once you have them configured correctly, a lot of deliverability problems fix themselves.</p>

<p>This post walks through what SPF, DKIM, and DMARC are, how they interact with each other, what a real setup looks like, and what to do if you’re not sure whether yours is working. No unnecessary jargon, no filler — just the practical explanation I wish I’d had the first time someone handed me a DNS panel and said “go figure it out.”</p>

<hr>

<!– ══ SPF ══ –>

<h2>SPF (Sender Policy Framework): Telling the World Who’s Allowed to Send on Your Behalf</h2>

<p>SPF — Sender Policy Framework — is a DNS record that lists every server authorized to send email from your domain. When someone receives a message from you, their mail server checks your SPF record and asks a simple question: did this email come from a server I’d expect to send for this domain? If the answer is no, that’s a strike against you.</p>

<p>The record itself lives in your DNS as a TXT entry and looks something like this:</p>

<div class=”code-block”><code>v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all</code></div>

<p>That breaks down pretty simply. <strong>v=spf1</strong> declares the version. Each <strong>include:</strong> pulls in the approved IP ranges for a sending platform — in this case, Google Workspace and Sendgrid. The <strong>ip4:</strong> adds a specific IP address. And the <strong>-all</strong> at the end is the policy: reject anything that doesn’t match.</p>

<div class=”callout”><strong>Hard fail vs. soft fail:</strong> The <code>-all</code> tag means hard fail — reject mail that doesn’t match. <code>~all</code> is a soft fail, which flags the message as suspicious but still allows delivery. For most production domains, hard fail is the right call. Soft fail is a common default that a lot of people never tighten up.</div>

<h3>The Lookup Limit Nobody Warns You About</h3>

<p>Here’s the thing about SPF that trips people up: there’s a hard limit of 10 DNS lookups per evaluation. Every <code>include:</code> statement in your record can trigger multiple lookups. If you’re sending through several platforms — say, a CRM, an ESP, and a transactional mail service — it’s surprisingly easy to hit that ceiling without realizing it.</p>

<p>When you exceed 10 lookups, SPF returns what’s called a PermError. Your record looks valid, everything seems fine, but SPF is actually failing silently. If that’s happening to you, the fix is to run your domain through an SPF flattening tool, which consolidates your includes into direct IP references and brings you back under the limit.</p>

<h3>What SPF Doesn’t Cover</h3>

<p>SPF validates the envelope sender — the technical delivery path — not the From address your recipient sees in their email client. A spammer can still spoof the visible From header while technically passing SPF. That’s not a flaw, exactly, it’s just the scope of what SPF was designed to do. DKIM and DMARC close the gaps SPF leaves open.</p>

<hr>

<!– ══ DKIM ══ –>

<h2>DKIM (DomainKeys Identified Mail): The Cryptographic Signature That Proves You Sent It</h2>

<p>DKIM — DomainKeys Identified Mail — takes a different approach than SPF. Rather than checking whether a server is authorized, DKIM uses a cryptographic signature to verify two things: that the email actually came from your domain, and that it wasn’t altered in transit.</p>

<p>When you send a message, your mail server generates a digital signature using a private key and embeds it in the email headers. The receiving server then pulls your public key from DNS and uses it to verify that signature. If it checks out, the message passes DKIM.</p>

<p>The DNS record lives at a subdomain that looks like <code>mail._domainkey.yourdomain.com</code>, and the record itself contains your public key:</p>

<div class=”code-block”><code>v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…</code></div>

<p>The long string after <strong>p=</strong> is the public key. You don’t generate it yourself — your ESP or mail infrastructure provider handles that and gives you the record to paste into DNS. The private key stays on your sending server and never gets published anywhere.</p>

<h3>Why DKIM Survives Forwarding When SPF Doesn’t</h3>

<p>This is worth understanding because it comes up a lot. When an email gets forwarded, the forwarding server’s IP almost certainly isn’t in your SPF record — so SPF breaks. DKIM, on the other hand, is tied to the message content itself. As long as the message headers and body haven’t been modified, the signature is still valid even after forwarding. This makes DKIM the more durable authentication signal of the two, and it’s the one DMARC leans on most heavily when forwarding is involved.</p>

<div class=”callout”><strong>Key length matters:</strong> If your DNS provider supports it, use a 2048-bit RSA key for DKIM. The older 1024-bit keys are considered weak by current standards. Most modern ESPs default to 2048-bit now, but if you set up DKIM a few years ago it’s worth checking.</div>

<h3>Selectors: How Multiple DKIM Keys Coexist</h3>

<p>A single domain can have multiple DKIM keys active at the same time — each identified by a different selector prefix in the DNS record name. This means each sending platform you use can have its own dedicated key with no conflicts. You’ll commonly see selectors like <code>google</code>, <code>k1</code>, or <code>s1</code> in the wild. None of that requires any configuration on your part; it’s handled by the platforms you’re using.</p>

<hr>

<!– ══ DMARC ══ –>

<h2>DMARC (Domain-based Message Authentication, Reporting & Conformance): The Layer That Ties It All Together</h2>

<p>DMARC — Domain-based Message Authentication, Reporting and Conformance — is what makes SPF and DKIM actually enforceable. Without DMARC, you can have perfect SPF and DKIM records and still have no control over what happens to mail that fails authentication, and no visibility into who’s using your domain to send messages.</p>

<p>DMARC adds two things that the other two protocols lack: a policy that tells receiving servers what to do with failing mail, and a reporting mechanism that sends you data about everything being sent under your domain — including mail you didn’t send.</p>

<p>The record lives at <code>_dmarc.yourdomain.com</code> and looks like this:</p>

<div class=”code-block”><code>v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=s;</code></div>

<h3>The Three Policy Levels</h3>

<p>The <strong>p=</strong> tag is the most consequential part of the record. There are three options:</p>

<ul>

<li><strong>p=none</strong> — Monitor-only. Emails that fail authentication are still delivered, but you start receiving reports about what’s happening. This is always where you should start.</li>

<li><strong>p=quarantine</strong> — Failing emails get routed to the spam or junk folder instead of the inbox. A useful middle ground before going to full enforcement.</li>

<li><strong>p=reject</strong> — Failing emails are rejected at the server level and never delivered. This is the end goal for any domain that’s serious about protecting its sender reputation and preventing spoofing.</li>

</ul>

<div class=”callout”><strong>Don’t skip to reject:</strong> Start at p=none for a few weeks, review your aggregate reports, make sure all your legitimate sending sources are fully authenticated, then move to quarantine, then reject. Jumping straight to reject before you know what’s sending on your behalf is a fast way to block your own mail.</div>

<h3>Alignment: The Part Most Explanations Skip</h3>

<p>DMARC introduces a concept called alignment that’s worth spending a minute on. For an email to pass DMARC, it’s not enough to just pass SPF or DKIM — the domain used in authentication also has to match (or organizationally align with) the domain in your visible From header.</p>

<p>There are two alignment modes. Strict alignment requires an exact match. Relaxed alignment — the default — allows subdomains to align with the root domain, so <code>mail.yourdomain.com</code> aligns with <code>yourdomain.com</code>. Relaxed is right for most use cases.</p>

<p>The reason alignment exists is to close the loophole where someone could technically pass SPF or DKIM using an entirely different domain than what appears in the From field. Alignment means that passing authentication and displaying a legitimate From address have to happen on the same domain.</p>

<h3>DMARC Reporting: What You Actually Get</h3>

<p>The <strong>rua=</strong> tag tells DMARC where to send aggregate reports. These XML files arrive daily from major mailbox providers and show a breakdown of all mail claiming to come from your domain — pass rates, failure reasons, sending IPs, and volume counts. They’re not exactly light reading in raw form, but free tools like Google Postmaster Tools and dmarcanalyzer.com turn them into something legible. If you’re running significant sending volume, a dedicated DMARC reporting platform is worth the subscription cost.</p>

<hr>

<!– ══ HOW THEY WORK TOGETHER ══ –>

<h2>How SPF, DKIM, and DMARC Work Together</h2>

<p>These three protocols are complementary, not interchangeable. Each one handles a different piece of the authentication problem:</p>

<ul>

<li><strong>SPF</strong> confirms the sending server is on the approved list for your domain.</li>

<li><strong>DKIM</strong> confirms the message is intact and genuinely signed by your domain.</li>

<li><strong>DMARC</strong> enforces a policy based on those results and reports back to you.</li>

</ul>

<p>The way I usually explain it: SPF is the bouncer checking IDs at the door. DKIM is the tamper-evident seal on the envelope. DMARC is the manager who decides what to do when either check fails — and sends you the incident report afterward.</p>

<p>Skipping any one of them leaves a real gap. No DMARC means no enforcement, even with solid SPF and DKIM. No DKIM means you’re exposed to replay attacks and message tampering, and your authentication falls apart when forwarding is involved. No SPF means no clear policy signal for receiving servers to reference.</p>

<table>

<thead>

<tr><th></th><th>SPF</th><th>DKIM</th><th>DMARC</th></tr>

</thead>

<tbody>

<tr><td>What it checks</td><td>Sending IP address</td><td>Message content & signature</td><td>SPF + DKIM policy & alignment</td></tr>

<tr><td>Lives in DNS</td><td>Yes (TXT)</td><td>Yes (TXT)</td><td>Yes (TXT)</td></tr>

<tr><td>Survives forwarding</td><td>No</td><td>Usually yes</td><td>Depends on what passes</td></tr>

<tr><td>Provides reports</td><td>No</td><td>No</td><td>Yes</td></tr>

<tr><td>Required for inbox</td><td>Yes</td><td>Yes</td><td>Strongly recommended</td></tr>

</tbody>

</table>

</div>

<hr>

<!– ══ SETUP ══ –>

<h2>How to Set Up SPF, DKIM, and DMARC: The Order That Actually Works</h2>

<p>Getting all three in place takes a few hours the first time — most of that is waiting for DNS to propagate and reviewing your first batch of DMARC reports. Here’s the sequence that avoids the most common mistakes:</p>

<h3>Start With DKIM</h3>

<p>DKIM keys are generated by your sending platform, not created manually. Log into your ESP or mail provider and find their DKIM or domain authentication settings. They’ll give you a DNS record to publish. Add it, wait for propagation, and verify it’s resolving correctly before you do anything else. Use MXToolbox’s DKIM lookup to confirm.</p>

<h3>Build Your SPF Record</h3>

<p>Make a complete list of everything that sends email from your domain — your main ESP, any CRM with email features, transactional mail services, your own mail server if you run one, and anything else. Each platform needs to be represented in your SPF record. Once you’ve got it written, publish it as a single TXT record on your root domain.</p>

<div class=”code-block”><code><span class=”comment”>; Example — Google Workspace + Sendgrid</span>

v=spf1 include:_spf.google.com include:sendgrid.net -all</code></div>

<p>Important: only one SPF TXT record per domain. If you accidentally create two, they conflict and SPF fails entirely. Combine everything into one record.</p>

<h3>Add DMARC at p=none First</h3>

<p>Publish your DMARC record pointing to an inbox you actually check. Let it run for at least two weeks before touching the policy level.</p>

<div class=”code-block”><code>v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100;</code></div>

<h3>Review Reports, Fix Gaps, Then Escalate</h3>

<p>Your aggregate reports will surface sending sources you missed. Add them to SPF, verify their DKIM setup, and keep going until a full reporting cycle comes back clean for all legitimate senders. Then move to quarantine, give it another week or two, and escalate to reject.</p>

<h3>Keep It Maintained</h3>

<p>Authentication isn’t set-and-forget infrastructure. Every time you add a new sending tool — a new CRM, a new ESP, a new transactional mail service — you need to update your SPF record and make sure DKIM is configured. Run a health check every few months through MXToolbox or Google Postmaster Tools to catch anything that’s drifted.</p>

<hr>

<!– ══ 2024 REQUIREMENTS ══ –>

<h2>The 2024 Gmail and Yahoo Requirements Changed the Baseline</h2>

<p>In early 2024, Google and Yahoo rolled out mandatory authentication requirements for bulk senders — anyone sending more than 5,000 messages a day to Gmail addresses. The requirements: SPF or DKIM authentication, a DMARC record at p=none or higher, and one-click unsubscribe on commercial email.</p>

<p>This affected a lot of senders who’d been getting away with partial or missing authentication. More importantly, it signaled something that’s been true for a while: authentication is no longer optional. The mailbox providers have been moving in this direction for years, and they’re not moving back.</p>

<p>If you’re using email as a meaningful channel, your authentication needs to be in order before you spend another hour on subject line testing or segmentation strategy. Everything downstream of authentication depends on it.</p>

<hr>

<!– ══ FAQ ══ –>

<h2>Frequently Asked Questions</h2>

<div class=”faq-q”>Do I really need all three — SPF, DKIM, and DMARC?</div>

<div class=”faq-a”>Yes, if deliverability matters to you. SPF and DKIM handle different parts of authentication and have different failure modes. DMARC is what turns those two signals into an enforceable policy and gives you visibility. Having two out of three leaves genuine gaps — and as of 2024, the major mailbox providers are actively checking for complete setups.</div>

</div>

<div class=”faq-q”>What happens if my emails fail SPF?</div>

<div class=”faq-a”>If you have a DMARC policy of p=quarantine or p=reject in place, failing SPF will cause your emails to be filtered to spam or rejected — unless DKIM passes and alignment is satisfied. At p=none, failures get logged in your reports but don’t immediately affect delivery. That’s the value of starting at p=none: you get the data without the risk of blocking your own mail.</div>

</div>

<div class=”faq-q”>Can I have more than one SPF record on my domain?</div>

<div class=”faq-a”>No. You can only have one SPF TXT record per domain. Publishing two creates a conflict that causes a PermError and SPF fails entirely. If you’re using multiple sending platforms, combine all of their include statements into a single record. This is one of the more common configuration mistakes I see.</div>

</div>

<div class=”faq-q”>What is DMARC alignment and why does it matter?</div>

<div class=”faq-a”>Alignment means the domain in your visible From address has to match — or organizationally align with — the domain used in your SPF or DKIM authentication. Without alignment, you could theoretically pass both SPF and DKIM using a completely different domain than what your recipients see. Alignment closes that loophole and ensures authentication and sender identity are tied to the same domain.</div>

</div>

<div class=”faq-q”>How long does DNS propagation take after I add these records?</div>

<div class=”faq-a”>Most changes propagate within 15 to 30 minutes with modern DNS providers, though technically it can take up to 48 hours. Use MXToolbox’s DNS lookup or whatsmydns.net to check propagation status from multiple locations before running any authentication tests.</div>

</div>

<div class=”faq-q”>What’s the difference between DMARC rua and ruf reports?</div>

<div class=”faq-a”>The rua tag points to where aggregate reports are delivered — daily XML summaries showing pass/fail counts by IP across all senders claiming to be your domain. The ruf tag is for forensic reports, which are message-level failure reports generated each time an email fails DMARC. Forensic reports can contain message content, which is why many providers have limited or disabled them for privacy reasons. Aggregate reports are the more actionable of the two and the ones you’ll actually use to monitor your setup.</div>

</div>

<div class=”faq-q”>My SPF and DKIM are both passing but emails still go to spam. What’s going on?</div>

<div class=”faq-a”>Authentication is necessary but not sufficient. If your technical authentication is clean, the issue is almost certainly reputation-related — your domain or sending IP has a history mailbox providers don’t trust, your list contains too many unengaged or invalid addresses, your content is triggering filters, or your unsubscribe rates are elevated. Think of authentication as getting yourself into the room. Your sender reputation and engagement history determine whether you stay.</div>

</div>

<div class=”faq-q”>How does Adaptix.ai handle SPF, DKIM, and DMARC for its users?</div>

<div class=”faq-a”>Adaptix.ai checks authentication status at setup and flags issues in plain language before they affect your deliverability. If your DMARC alignment is broken or your SPF record is missing a sending source, the platform tells you what’s wrong and what to fix — you don’t have to dig through raw XML reports to figure it out. Authentication is built into the foundation of how Adaptix approaches email infrastructure.</div>

</div>

<hr>

<!– ══ CONCLUSION ══ –>

<h2>Wrapping Up</h2>

<p>SPF, DKIM, and DMARC are not complicated once you understand what each one is actually doing. SPF defines who’s allowed to send. DKIM proves the message is legitimate and unchanged. DMARC enforces both and keeps you informed.</p>

<p>The setup takes an afternoon the first time. After that, it’s light maintenance — update your SPF record when you add a new sending platform, check your DMARC reports periodically, and run a DNS health check every few months. That’s genuinely the whole job.</p>

<p>The payoff is real: better inbox placement, protection against domain spoofing, and the data to actually understand what’s happening with your sending infrastructure. If you’re building a serious email program, this is the foundation. Get it right before you optimize anything else.</p>

<div class=”callout”><strong>Free audit:</strong> Run your domain through MXToolbox’s Email Health Report. It checks SPF, DKIM, and DMARC in about 30 seconds and tells you exactly what needs attention.</div>

</div><!– /post-body –>

<p>Published by <strong>Adaptix.ai</strong>  ·  AI-Powered Email Marketing Platform</p>

</div>

</div><!– /wrapper –>

<!– ═══ HIDDEN WORDPRESS-READY HTML ═══ –>

<!– Adaptix.ai Blog Post: SPF, DKIM, and DMARC –>

<hr/>

<h2>SPF (Sender Policy Framework): Telling the World Who’s Allowed to Send on Your Behalf</h2>

<p>The record itself lives in your DNS as a TXT entry and looks something like this:</p>

<pre><code>v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all</code></pre>

<blockquote><p><strong>Hard fail vs. soft fail:</strong> The <code>-all</code> tag means hard fail — reject mail that doesn’t match. <code>~all</code> is a soft fail, which flags the message as suspicious but still allows delivery. For most production domains, hard fail is the right call. Soft fail is a common default that a lot of people never tighten up.</p></blockquote>

<h3>The Lookup Limit Nobody Warns You About</h3>

<h3>What SPF Doesn’t Cover</h3>

<p>SPF validates the envelope sender — the technical delivery path — not the From address your recipient sees in their email client. A spammer can still spoof the visible From header while technically passing SPF. That’s not a flaw, exactly; it’s just the scope of what SPF was designed to do. DKIM and DMARC close the gaps SPF leaves open.</p>

<hr/>

<h2>DKIM (DomainKeys Identified Mail): The Cryptographic Signature That Proves You Sent It</h2>

<p>The DNS record lives at a subdomain that looks like <code>mail._domainkey.yourdomain.com</code>, and the record itself contains your public key:</p>

<pre><code>v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…</code></pre>

<h3>Why DKIM Survives Forwarding When SPF Doesn’t</h3>

<blockquote><p><strong>Key length matters:</strong> If your DNS provider supports it, use a 2048-bit RSA key for DKIM. The older 1024-bit keys are considered weak by current standards. Most modern ESPs default to 2048-bit now, but if you set up DKIM a few years ago it’s worth checking.</p></blockquote>

<h3>Selectors: How Multiple DKIM Keys Coexist</h3>

<hr/>

<h2>DMARC (Domain-based Message Authentication, Reporting &amp; Conformance): The Layer That Ties It All Together</h2>

<p>The record lives at <code>_dmarc.yourdomain.com</code> and looks like this:</p>

<pre><code>v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=s;</code></pre>

<h3>The Three Policy Levels</h3>

<p>The <strong>p=</strong> tag is the most consequential part of the record. There are three options:</p>

<ul>

<li><strong>p=quarantine</strong> — Failing emails get routed to the spam or junk folder instead of the inbox. A useful middle ground before going to full enforcement.</li>

</ul>

<blockquote><p><strong>Don’t skip to reject:</strong> Start at p=none for a few weeks, review your aggregate reports, make sure all your legitimate sending sources are fully authenticated, then move to quarantine, then reject. Jumping straight to reject before you know what’s sending on your behalf is a fast way to block your own mail.</p></blockquote>

<h3>Alignment: The Part Most Explanations Skip</h3>

<h3>DMARC Reporting: What You Actually Get</h3>

<hr/>

<h2>How SPF, DKIM, and DMARC Work Together</h2>

<p>These three protocols are complementary, not interchangeable. Each one handles a different piece of the authentication problem:</p>

<ul>

<li><strong>SPF</strong> confirms the sending server is on the approved list for your domain.</li>

<li><strong>DKIM</strong> confirms the message is intact and genuinely signed by your domain.</li>

<li><strong>DMARC</strong> enforces a policy based on those results and reports back to you.</li>

</ul>

<hr/>

<h2>How to Set Up SPF, DKIM, and DMARC: The Order That Actually Works</h2>

<h3>Start With DKIM</h3>

<h3>Build Your SPF Record</h3>

<pre><code>; Example — Google Workspace + Sendgrid

v=spf1 include:_spf.google.com include:sendgrid.net -all</code></pre>

<p>Important: only one SPF TXT record per domain. If you accidentally create two, they conflict and SPF fails entirely. Combine everything into one record.</p>

<h3>Add DMARC at p=none First</h3>

<p>Publish your DMARC record pointing to an inbox you actually check. Let it run for at least two weeks before touching the policy level.</p>

<pre><code>v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100;</code></pre>

<h3>Review Reports, Fix Gaps, Then Escalate</h3>

<h3>Keep It Maintained</h3>

<hr/>

<h2>The 2024 Gmail and Yahoo Requirements Changed the Baseline</h2>

<hr/>

<h2>Frequently Asked Questions</h2>

<h3>Do I really need all three — SPF, DKIM, and DMARC?</h3>

<p>Yes, if deliverability matters to you. SPF and DKIM handle different parts of authentication and have different failure modes. DMARC is what turns those two signals into an enforceable policy and gives you visibility. Having two out of three leaves genuine gaps — and as of 2024, the major mailbox providers are actively checking for complete setups.</p>

<h3>What happens if my emails fail SPF?</h3>

<p>If you have a DMARC policy of p=quarantine or p=reject in place, failing SPF will cause your emails to be filtered to spam or rejected — unless DKIM passes and alignment is satisfied. At p=none, failures get logged in your reports but don’t immediately affect delivery. That’s the value of starting at p=none: you get the data without the risk of blocking your own mail.</p>

<h3>Can I have more than one SPF record on my domain?</h3>

<p>No. You can only have one SPF TXT record per domain. Publishing two creates a conflict that causes a PermError and SPF fails entirely. If you’re using multiple sending platforms, combine all of their include statements into a single record. This is one of the more common configuration mistakes I see.</p>

<h3>What is DMARC alignment and why does it matter?</h3>

<p>Alignment means the domain in your visible From address has to match — or organizationally align with — the domain used in your SPF or DKIM authentication. Without alignment, you could theoretically pass both SPF and DKIM using a completely different domain than what your recipients see. Alignment closes that loophole and ensures authentication and sender identity are tied to the same domain.</p>

<h3>How long does DNS propagation take after I add these records?</h3>

<p>Most changes propagate within 15 to 30 minutes with modern DNS providers, though technically it can take up to 48 hours. Use MXToolbox’s DNS lookup or whatsmydns.net to check propagation status from multiple locations before running any authentication tests.</p>

<h3>What’s the difference between DMARC rua and ruf reports?</h3>

<p>The rua tag points to where aggregate reports are delivered — daily XML summaries showing pass/fail counts by IP across all senders claiming to be your domain. The ruf tag is for forensic reports, which are message-level failure reports generated each time an email fails DMARC. Forensic reports can contain message content, which is why many providers have limited or disabled them for privacy reasons. Aggregate reports are the more actionable of the two and the ones you’ll actually use to monitor your setup.</p>

<h3>My SPF and DKIM are both passing but emails still go to spam. What’s going on?</h3>

<p>Authentication is necessary but not sufficient. If your technical authentication is clean, the issue is almost certainly reputation-related — your domain or sending IP has a history mailbox providers don’t trust, your list contains too many unengaged or invalid addresses, your content is triggering filters, or your unsubscribe rates are elevated. Think of authentication as getting yourself into the room. Your sender reputation and engagement history determine whether you stay.</p>

<h3>How does Adaptix.ai handle SPF, DKIM, and DMARC for its users?</h3>

<p>Adaptix.ai checks authentication status at setup and flags issues in plain language before they affect your deliverability. If your DMARC alignment is broken or your SPF record is missing a sending source, the platform tells you what’s wrong and what to fix — you don’t have to dig through raw XML reports to figure it out. Authentication is built into the foundation of how Adaptix approaches email infrastructure.</p>

<hr/>

<h2>Wrapping Up</h2>

<blockquote><p><strong>Free audit:</strong> Run your domain through MXToolbox’s Email Health Report. It checks SPF, DKIM, and DMARC in about 30 seconds and tells you exactly what needs attention.</p></blockquote>

<!– WP_END –></div>

function copyWP(btn) {

const raw = document.getElementById(‘wp-content’).innerHTML;

const start = raw.indexOf(‘<!– WP_START –>’) + ‘<!– WP_START –>’.length;

const end = raw.indexOf(‘<!– WP_END –>’);

let wp = raw.substring(start, end).trim();

// decode HTML entities so we get real HTML tags

const ta = document.createElement(‘textarea’);

ta.innerHTML = wp;

const decoded = ta.value.trim();

navigator.clipboard.writeText(decoded).then(() => {

btn.textContent = ‘✓ Copied!’;

btn.classList.add(‘copied’);

setTimeout(() => { btn.textContent = ‘⎘ Copy WordPress HTML’; btn.classList.remove(‘copied’); }, 2500);

});

}

</script>

</body>

</html>

How to Use Adaptix for AI-Driven Lead Generation

Legal

Community

Sign Up for our Brochure

Your account has been successfully created!