Email Security with SPF, DKIM, and DMARC

Email spoofing allows attackers to send messages that appear to come from your domain. Without proper authentication, anyone can send an email claiming to be from ceo@yourdomain.com. SPF, DKIM, and DMARC are DNS-based standards that help receiving mail servers verify legitimate emails. All three rely on TXT records published in your DNS zone, making proper DNS configuration essential.

This is the pillar guide for the full stack. For focused implementation details, use the dedicated pages:

• SPF record explained
• DKIM explained
• DMARC explained
• MTA-STS and TLS-RPT for encrypted inbound SMTP delivery
• Google Workspace DNS setup
• Microsoft 365 DNS setup

Adding Postscale to an existing domain

Use the Postscale DNS review and approval walkthrough for the actual setup sequence: merge compatible SPF, preserve DMARC, add the supplied DKIM selector and review the record changes. Application sending keeps your existing receiving MX. Personal forwarding is a separate receiving cutover.

What You'll Learn

• How SPF declares authorized mail servers
• How DKIM cryptographically signs emails
• How DMARC defines policies for failed authentication
• Setting up all three via DNScale dashboard and API
• Testing and validating your configuration

SPF (Sender Policy Framework)

What SPF Does

SPF lets you specify which IP addresses and mail servers can send email for your domain. Receiving servers check your SPF record to verify the sender is authorized. SPF records are published as TXT records at the envelope-sender domain (or the HELO identity when applicable), so understanding how DNS works is helpful context.

For a deeper standalone walkthrough, see SPF record explained.

SPF Record Syntax

An SPF record is a TXT record at the domain being evaluated:

v=spf1 [mechanisms] [qualifier]all

Common SPF Examples

Google Workspace:

v=spf1 include:_spf.google.com ~all

Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Multiple providers:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Custom mail server:

v=spf1 ip4:203.0.113.5 mx ~all

SPF Best Practices

1. Start with ~all (soft fail), move to -all after testing
2. Keep within the 10 DNS-querying-term limit, including nested policies
3. Include all sending sources: transactional email, marketing platforms, etc.
4. If you use multiple mail services, verify each one is covered before enforcing -all

SPF alone does not prevent spoofing of the visible "From" header. It only validates the envelope sender. Combine it with DKIM and DMARC for comprehensive protection.

DKIM (DomainKeys Identified Mail)

What DKIM Does

DKIM adds a digital signature to outgoing emails. Your mail server signs each email with a private key, and you publish the corresponding public key in DNS. Receiving servers use this public key to verify that the signed content was not modified and that the signer controls the corresponding domain key. Like SPF, the public key is stored as a TXT record.

For selectors, key rotation, and DNS key formatting, see DKIM explained.

How DKIM Works

1. Your mail server generates a cryptographic signature using a private key
2. The signature is added to the email's headers
3. Receiving servers look up your DKIM public key in DNS
4. They verify the signature matches the email content
5. If valid, the email passes DKIM authentication

DKIM Record Syntax

A DKIM record is a TXT record at selector._domainkey.yourdomain.com:

selector._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

DKIM Selectors

The selector is a name that identifies which key to use. This allows:

• Low-disruption key rotation
• Different keys for different mail services
• Multiple keys active simultaneously

Common selector patterns:

• google for Google Workspace
• selector1, selector2 for Microsoft 365
• k1, k2, k3 for custom setups
• mailjet, sendgrid for third-party services

Getting Your DKIM Keys

DKIM keys are generated by your email provider. Here's where to find them:

Google Workspace:

1. Admin Console → Apps → Google Workspace → Gmail
2. Authenticate email → Generate new record
3. Publish the supplied TXT value, then enable authentication in Google Workspace

Microsoft 365:

1. Microsoft 365 Defender → Email & collaboration → Policies
2. DKIM → Select domain → Create DKIM keys
3. Publish the two supplied CNAME records, then enable DKIM signing

Third-party services (SendGrid, Mailjet, etc.):

• Check your provider's dashboard for DNS settings
• They'll provide the selector name and public key

DKIM Record Examples

Google Workspace:

google._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Microsoft 365: publish CNAME, not TXT, at selector1._domainkey and selector2._domainkey. Copy the exact tenant-specific targets from Microsoft's DKIM configuration. Do not construct targets from an example; their format depends on the tenant.

Custom/Third-party:

mail._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

DKIM Best Practices

1. Use 2048-bit keys - 1024-bit keys are increasingly vulnerable
2. Rotate keys periodically - At least annually for security
3. Keep private keys secure - Never expose them in DNS or logs
4. Use unique selectors - Different selectors for each service
5. Test before enforcing DMARC - Ensure DKIM passes before p=reject

DKIM key rotation is conceptually similar to DNSSEC key rollover. In both cases, you must publish the new key before removing the old one to avoid validation failures during the transition.

DMARC (Domain-based Message Authentication)

What DMARC Does

DMARC builds on SPF (and DKIM) to provide:

• Alignment of an authenticated SPF or DKIM domain with the visible From domain
• A requested policy for messages that fail that alignment
• Reporting so you can monitor authentication results

DMARC is a critical layer in DNS security best practices because, when deployed at enforcement and honored by receivers, it reduces direct domain spoofing in phishing campaigns.

For alignment, reporting, and rollout details, see DMARC explained.

DMARC Record Syntax

A DMARC record is a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=policy; [optional tags]

Required Tags:

Optional Tags:

DMARC Policy Options

DMARC Examples

Monitor mode:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Quarantine mode:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Reject mode:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Recommended Rollout

1. Inventory legitimate senders and begin with p=none if no policy exists.
2. Review reports over a representative sending cycle and repair failing streams.
3. Move to p=quarantine, then p=reject when the evidence supports it.

RFC 9989 removed pct; do not depend on percentage-based rollout. Keep a working existing policy when adding another sender.

Be patient with the rollout. Rushing to p=reject before verifying all legitimate sending sources are covered can cause real business email to be blocked. Review your DMARC aggregate reports carefully at each stage.

Setup via DNScale Dashboard

Before adding records, review the existing zone. Edit an existing SPF policy instead of creating a second one; preserve unrelated TXT records and working DKIM selectors. The examples below are placeholders for a new configuration.

Create SPF Record

1. Log in at dnscale.eu
2. Select your domain
3. Click Add Record
4. Configure:
   • Name: Leave empty (apex)
   • Type: TXT
   • Content: v=spf1 include:_spf.google.com ~all
   • TTL: 3600
5. Click Create Record

Create DKIM Record

1. Get your DKIM public key from your email provider (see "Getting Your DKIM Keys" above)
2. Click Add Record
3. Configure:
   • Name: google._domainkey (or your provider's selector)
   • Type: TXT
   • Content: v=DKIM1; k=rsa; p=MIIBIjANBgkq... (your public key)
   • TTL: 3600
4. Click Create Record

For Microsoft 365, use the provider-supplied CNAME records for both selectors instead of the TXT example. Publishing DNS is followed by enabling signing at the mail provider.

Create DMARC Record

1. Click Add Record
2. Configure:
   • Name: _dmarc
   • Type: TXT
   • Content: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
   • TTL: 3600
3. Click Create Record

Setting sensible TTL values on email authentication records matters. Use 3600 seconds (1 hour) as a baseline. See our TTL best practices guide for recommendations.

Setup via DNScale API

Authentication

export DNSCALE_API_KEY="your-api-key"

Get Zone ID

curl -s "https://api.dnscale.eu/v1/zones" \
  -H "Authorization: Bearer $DNSCALE_API_KEY" | jq '.data.zones[] | {id, name}'

Create SPF Record

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer $DNSCALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "TXT",
    "content": "v=spf1 include:_spf.google.com ~all",
    "ttl": 3600
  }'

Create DKIM Record

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer $DNSCALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "google._domainkey",
    "type": "TXT",
    "content": "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...",
    "ttl": 3600
  }'

Replace google._domainkey with your selector and the public key with your actual DKIM key.

Create DMARC Record

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer $DNSCALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_dmarc",
    "type": "TXT",
    "content": "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com",
    "ttl": 3600
  }'

Verify Records

curl -s "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer $DNSCALE_API_KEY" | jq '.data.records[] | select(.type == "TXT")'

If you manage DNS as code, you can also deploy email authentication records through Terraform or DNSControl, or even set up multi-provider DNS to keep your email records synchronized across providers.

The SPF standard defines the evaluation limits; DMARC's current specification defines alignment and requested receiver policy. These checks reduce direct domain spoofing, but do not prevent display-name or lookalike-domain attacks.

Testing and Validation

Online Tools

• MXToolbox SPF Check
• MXToolbox DKIM Check
• MXToolbox DMARC Check
• DMARC Analyzer
• Mail Tester - Send a test email to check all authentication

Command Line

# Check SPF
dig TXT yourdomain.com +short
 
# Check DKIM (replace 'google' with your selector)
dig TXT google._domainkey.yourdomain.com +short
 
# Check DMARC
dig TXT _dmarc.yourdomain.com +short

If changes aren't appearing, review how DNS propagation works and consider flushing your local DNS cache.

Send a Test Email

After enabling signing, send to an inbox you control and inspect its trusted Authentication-Results headers. DNS lookups alone cannot establish delivery:

1. Send an email to a Gmail account
2. Open the email → Click the three dots → "Show original"
3. Look for:
   • spf=pass
   • dkim=pass
   • dmarc=pass
4. Compare the authenticated domains with the visible From domain; retain a redacted copy of the received headers for diagnosis.
5. Confirm actual receipt and test existing inbound mail separately.

How Email Authentication Fits Into Broader DNS Security

SPF, DKIM, and DMARC are part of a wider set of DNS-based security mechanisms. Consider pairing them with:

• CAA records to control which certificate authorities can issue SSL/TLS certificates for your domain
• DNSSEC to cryptographically sign your DNS zone and prevent DNS cache poisoning
• TLSA records for DANE-based certificate pinning on your mail server (requires DNSSEC)
• PTR records for reverse DNS, which many mail servers check alongside SPF
• MTA-STS and TLS-RPT to enforce valid TLS for inbound SMTP delivery and receive transport-security reports

Together, these records create a layered defence that protects both your domain's email and web traffic.

Summary

How They Work Together:

• SPF verifies the sending server is authorized
• DKIM verifies the email content wasn't modified
• DMARC combines authentication with visible-From alignment and a requested failure policy

Recommended Implementation Order:

1. Set up SPF first (easiest)
2. Configure DKIM with your email provider
3. Add DMARC in monitor mode (p=none)
4. Review reports, fix issues
5. Gradually enforce DMARC (p=quarantine → p=reject)