SPF vs DKIM vs DMARC: Email Authentication Explained

Email authentication has three protocols that work together. Each solves a different problem:

• Without SPF: Receivers can't verify you're authorized to send. Gmail rejects unauthenticated mail since February 2024 (source: blog.google/products/gmail/gmail-security-authentication-spam-protection).
• Without DKIM: Your emails can be modified in transit. Some providers add spam warnings to unsigned messages.
• Without DMARC: You have no control over what happens to spoofed emails using your domain. This damages your domain reputation even if YOU aren't the spammer.

InboxKit configures all three automatically when you add a domain. The screenshot above shows SPF, DKIM, and DMARC green indicators on all active domains.

SPF tells receiving servers which IP addresses and mail servers are authorized to send email on behalf of your domain.

How it works: 1. You publish a TXT record listing authorized senders 2. Receiving server looks up your SPF record 3. Checks if the sending server's IP matches 4. Passes or fails the check

Example SPF records:

SPF qualifiers explained:

Common SPF mistake: Having more than 10 DNS lookups. Each include: counts as a lookup. If you exceed 10, SPF fails entirely (source: RFC 7208, Section 4.6.4).

InboxKit's approach: We set the correct SPF record for your mailbox type (Google or Microsoft) automatically. No manual DNS editing required.

DKIM adds a cryptographic signature to every email you send. The receiving server verifies the signature using your public key published in DNS.

How it works: 1. Your mail server signs each email with a private key 2. The signature is added as a DKIM-Signature header 3. Receiving server retrieves your public key from DNS 4. Verifies the signature matches. proving the email wasn't modified

DKIM key sizes:

Source: Google recommends 2048-bit keys (support.google.com/a/answer/174124). Microsoft 365 also uses 2048-bit by default.

What DKIM looks like in DNS: ` selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjAN..." `

The selector is a label chosen by your email provider. Google uses google as the default selector. Microsoft uses selector1 and selector2.

InboxKit generates and publishes DKIM keys automatically for both Google Workspace and Microsoft 365 accounts during provisioning.

DMARC builds on SPF and DKIM. It tells receiving servers what to do when authentication fails AND sends you reports about who's using your domain to send email.

DMARC policies:

Example DMARC records:

Source: Google requires at minimum p=none for bulk senders since February 2024 (support.google.com/a/answer/2466580). The RFC is at tools.ietf.org/html/rfc7489.

DMARC alignment: DMARC checks that the domain in the From header aligns with either SPF or DKIM. There are two modes:

InboxKit sets p=none by default during domain setup, giving you monitoring without risk. You can upgrade to p=quarantine or p=reject through the dashboard once you've verified no legitimate mail is failing.

The three protocols create a chain of trust:

• SPF passes AND aligns with From domain, OR
• DKIM passes AND aligns with From domain

It doesn't need both. just one aligned pass is enough. This is important because email forwarding often breaks SPF but preserves DKIM.

Impact on deliverability (from Validity 2025 Benchmark Report):

The difference between no authentication and full authentication is ~60 percentage points of inbox placement. For cold email, this is the difference between campaigns that work and campaigns that go entirely to spam.

InboxKit automates the entire chain. Every domain gets SPF, DKIM, and DMARC configured in under 10 minutes. The domains dashboard shows real-time status for all three protocols across every domain (see screenshot).