SPF, DKIM, DMARC Checker - Verify Email Authentication Records

What are SPF, DKIM, and DMARC?

SPF, DKIM, and DMARC are three DNS-based email authentication protocols that work together to verify sender identity, prevent email spoofing, and protect your domain from being used in phishing attacks. Together, they form the foundation of modern email security.

SPF (Sender Policy Framework)

SPF is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. When a receiving mail server gets an email, it checks the SPF record of the sender's domain to verify the email came from an authorized server. Without SPF, anyone can send emails pretending to be from your domain.

An SPF record looks like: v=spf1 include:_spf.google.com ~all. This tells receiving servers that only Google's mail servers are authorized to send mail for your domain. The ~all means emails from other servers should be treated as suspicious (soft fail).

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to every outgoing email. The sending server signs each message with a private key, and the corresponding public key is published in your DNS records. Receiving servers use this public key to verify the signature, confirming the email was not altered in transit and truly originated from your domain.

DKIM records are stored as TXT records at a selector-specific subdomain, such as selector1._domainkey.example.com. The signature itself is included as a header in each email message, providing cryptographic proof of authenticity.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC builds on SPF and DKIM by telling receiving servers what to do when an email fails authentication. You can instruct servers to monitor (none), quarantine, or reject unauthenticated emails. DMARC also provides reporting so you can see who is sending email using your domain.

A DMARC record looks like: v=DMARC1; p=reject; rua=mailto:dmarc@example.com. This tells receiving servers to reject emails that fail both SPF and DKIM checks, and to send aggregate reports to the specified email address.

Why Email Authentication Matters

Proper email authentication is critical for deliverability, security, and brand reputation. Without it, your emails are more likely to land in spam folders or be rejected entirely.

Prevent Email Spoofing and Phishing

Without authentication records, cybercriminals can easily forge emails that appear to come from your domain. This puts your customers, partners, and employees at risk of phishing attacks. SPF, DKIM, and DMARC make it significantly harder for attackers to impersonate your brand. According to the FBI, business email compromise caused over $2.7 billion in losses in 2022 alone. Proper authentication is your first line of defense against these attacks.

Improve Email Deliverability

Major email providers like Gmail, Outlook, and Yahoo use authentication records to determine whether to deliver your email to the inbox, spam folder, or reject it entirely. Google requires SPF and DKIM for all bulk senders as of February 2024, and DMARC is strongly recommended. Our email deliverability checker can help you identify and fix authentication issues before they impact your campaigns.

Protect Your Brand Reputation

When someone spoofs your domain to send spam or malicious emails, it damages your brand's reputation and erodes customer trust. DMARC reporting gives you visibility into who is sending email using your domain, allowing you to identify and stop unauthorized use. Brands with proper DMARC enforcement see up to 10% improvement in email open rates because recipients trust their messages.

Meet Compliance Requirements

Many industries and regulatory frameworks now require email authentication. PCI DSS, HIPAA, and various government mandates increasingly specify SPF, DKIM, and DMARC as baseline security controls. Google and Yahoo's 2024 sender requirements mandate authentication for anyone sending more than 5,000 emails per day. Using our email verification service alongside proper authentication ensures full compliance.

How to Check Your SPF Record

Checking your SPF record is the first step in verifying your email authentication setup. An SPF record tells receiving mail servers which IP addresses and servers are authorized to send email for your domain. Here is a step-by-step guide to checking and validating your SPF record.

1

Enter Your Domain Above

Type your domain name (without https:// or www) into our checker tool. Our system performs an instant DNS lookup to find your SPF TXT record. You can also use command-line tools like nslookup -type=TXT example.com or dig TXT example.com.

2

Review the SPF Record

A valid SPF record starts with v=spf1 and lists authorized senders using mechanisms like include:, ip4:, ip6:, and a:. It ends with a qualifier: -all (hard fail), ~all (soft fail), or ?all (neutral). Hard fail (-all) is recommended for maximum security.

3

Check for Common Issues

Ensure you have only one SPF record (multiple records cause failures). Verify the record does not exceed 10 DNS lookups (the SPF specification limit). Check that all your sending services are listed — missing an ESP or transactional email service is a common cause of SPF failures.

4

Test with Real Emails

After verifying your SPF record, send test emails to check that they pass SPF authentication. View email headers in Gmail (Show Original) or Outlook to see SPF pass/fail results. Use our email domain checker for comprehensive domain analysis.

How to Check Your DKIM Record

DKIM verification requires knowing your DKIM selector, which varies by email provider. Our tool automatically checks common selectors, but you can also look up your specific DKIM record manually. Here is how to verify that your DKIM signing is working correctly.

1

Find Your DKIM Selector

Your DKIM selector is specific to your email provider. For Google Workspace, it is typically google. For Microsoft 365, it is selector1 and selector2. For other providers, check your email headers — look for the DKIM-Signature header and find the s= value. That is your selector.

2

Look Up the DKIM Record

The DKIM public key is stored at selector._domainkey.yourdomain.com. Our tool checks this automatically for common selectors. You can also use dig TXT selector._domainkey.example.com from the command line. The record should contain a p= value with the public key.

3

Validate the Key

Ensure the public key in your DNS matches the private key used by your mail server. Send a test email and check the DKIM signature in the headers. A valid DKIM signature shows dkim=pass in the Authentication-Results header. An expired or mismatched key results in dkim=fail.

4

Rotate Keys Regularly

Security best practices recommend rotating DKIM keys every 6 to 12 months. Use 2048-bit keys for maximum security (1024-bit is the minimum). When rotating, publish the new key before switching the signing configuration, then remove the old key after a transition period.

How to Check Your DMARC Record

DMARC ties SPF and DKIM together and tells receiving servers what to do with unauthenticated emails. A properly configured DMARC policy is essential for protecting your domain and getting visibility into email authentication failures. Follow these steps to check and optimize your DMARC setup.

1

Look Up Your DMARC Record

DMARC records are published at _dmarc.yourdomain.com. Our tool checks this automatically. The record starts with v=DMARC1 and includes a policy (p=) that can be none (monitor only), quarantine (send to spam), or reject (block entirely).

2

Understand Your Policy

Start with p=none to monitor without affecting delivery. Review DMARC reports to identify legitimate senders that may be failing authentication. Once all legitimate sources pass, gradually move to p=quarantine and then p=reject for maximum protection.

3

Configure Reporting

Add rua=mailto:dmarc-reports@yourdomain.com to receive aggregate reports showing who is sending email using your domain. Add ruf=mailto:dmarc-forensic@yourdomain.com for forensic reports with details on individual failures. These reports are invaluable for identifying unauthorized senders.

4

Monitor and Enforce

Regularly review DMARC reports to catch new unauthorized senders. Use the pct= tag to gradually roll out enforcement (e.g., pct=25 applies the policy to 25% of emails). Once confident, set pct=100 and p=reject for full protection.

Common SPF/DKIM/DMARC Errors and Fixes

Authentication errors are common and often easy to fix once identified. Here are the most frequent issues we see when checking email authentication records.

Error	Cause	Fix
SPF PermError: Too many DNS lookups	SPF record exceeds the 10 DNS lookup limit due to too many `include:` mechanisms	Consolidate include statements, use IP addresses directly, or use SPF flattening services to reduce lookups
Multiple SPF records found	Domain has more than one TXT record starting with `v=spf1`	Merge all SPF mechanisms into a single record. Only one SPF record is allowed per domain
DKIM signature does not verify	Public key in DNS does not match private key used for signing, or the message was modified in transit	Regenerate DKIM keys and update both the DNS record and mail server configuration simultaneously
DKIM record not found	DKIM TXT record is missing from DNS or the selector name is incorrect	Verify the correct selector name, then publish the DKIM TXT record at selector._domainkey.yourdomain.com
DMARC record not found	No TXT record exists at _dmarc.yourdomain.com	Create a DMARC record starting with `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`
DMARC alignment failure	The domain in SPF/DKIM does not align with the From: header domain	Ensure SPF and DKIM use the same domain as the From: header, or set DMARC alignment to relaxed mode (`aspf=r; adkim=r`)
SPF soft fail (~all) instead of hard fail	Using `~all` instead of `-all` means unauthorized emails are flagged but not rejected	After confirming all legitimate senders are listed, change `~all` to `-all` for strict enforcement
DMARC policy set to none	`p=none` means unauthenticated emails are still delivered normally	Monitor DMARC reports, then gradually move to `p=quarantine` and finally `p=reject` for full protection

Setting Up Email Authentication

If you do not have email authentication configured yet, here is how to set up SPF, DKIM, and DMARC for your domain. These DNS records protect your emails and improve deliverability.

Step 1: Set Up SPF

Add a TXT record to your domain's DNS with value:

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

Replace the include mechanism with your email provider's SPF include. For multiple providers, list all includes in a single record. Common includes: include:sendgrid.net, include:mailgun.org, include:spf.protection.outlook.com. The record goes on your root domain as a TXT record.

Step 2: Set Up DKIM

Generate a DKIM key pair through your email provider's admin console. Add the public key as a TXT record at:

selector._domainkey.yourdomain.com

For Google Workspace, navigate to Admin > Apps > Google Workspace > Gmail > Authenticate email. For Microsoft 365, go to Defender > Email & Collaboration > Policies > DKIM. Most ESPs like SendGrid, Mailchimp, and Mailgun provide DKIM setup in their domain authentication settings.

Step 3: Set Up DMARC

Add a TXT record at _dmarc.yourdomain.com with value:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

Start with p=none to monitor and collect reports without impacting mail flow. After 2 to 4 weeks of monitoring, move to p=quarantine, then p=reject once you are confident all legitimate emails pass authentication. Use a DMARC report analyzer to process the XML reports.

Need help verifying your setup? Use our email domain checker to confirm your DNS records are correctly configured, or check your email deliverability to see the full picture.

How to Check Your Email Authentication Records

Checking SPF, DKIM, and DMARC records is the single most important step you can take to diagnose email deliverability problems. Whether your marketing campaigns are landing in spam, your transactional emails are being rejected, or you suspect someone is spoofing your domain, an email authentication check reveals exactly what is configured and what is missing. Our SPF DKIM DMARC checker automates the entire process so you do not need to run manual DNS queries.

Step 1: Enter Your Domain Name

Scroll to the checker tool at the top of this page and type your root domain (for example, yourbusiness.com) without any protocol prefix. If you send email from a subdomain such as mail.yourbusiness.com, enter the subdomain instead. The tool performs real-time DNS lookups against authoritative nameservers, so results reflect the current state of your records.

Step 2: Review SPF Results

The checker retrieves your SPF TXT record and validates its syntax. It verifies that the record begins with v=spf1, counts the number of DNS lookup mechanisms (must be 10 or fewer), and checks whether the record ends with a proper qualifier (-all, ~all, or ?all). If no SPF record is found, the tool flags this as a critical issue because emails from your domain have no sender authorization.

Step 3: Review DKIM Results

Our tool probes common DKIM selectors such as google, selector1, selector2, default, k1, and provider-specific selectors for services like SendGrid, Mailchimp, and Amazon SES. For each discovered selector, the tool validates the public key length and format. A missing or misconfigured DKIM record means your outgoing emails lack a cryptographic signature, which reduces trust with receiving mail servers.

Step 4: Review DMARC Results

The checker queries _dmarc.yourdomain.com and parses the DMARC policy tag (p=), subdomain policy (sp=), alignment settings (aspf= and adkim=), and reporting addresses (rua= and ruf=). If your DMARC policy is set to none, the tool recommends a path toward enforcement. If no DMARC record exists, this is flagged because it means receiving servers have no instruction on how to handle authentication failures.

Step 5: Review MX Records and Overall Score

Beyond authentication records, the tool checks your MX records to confirm that your domain has valid mail exchange servers configured. The overall authentication score combines SPF, DKIM, DMARC, and MX results into a single pass or fail assessment. Use this score alongside our email deliverability checker to get a complete picture of your sending infrastructure health.

Step 6: Fix Issues and Re-Check

After making DNS changes, allow 5 to 60 minutes for propagation (depending on your TTL settings) and run the check again. DNS changes are not instant, so re-checking too soon may show stale results. Once all records pass validation, send a test email to a Gmail or Yahoo account and inspect the message headers to confirm spf=pass, dkim=pass, and dmarc=pass appear in the Authentication-Results header.

Understanding SPF Records — Syntax & Examples

SPF (Sender Policy Framework) is the oldest of the three email authentication protocols, defined in RFC 7208. It works by publishing a DNS TXT record on your domain that lists every server authorized to send email on your behalf. When a receiving server gets an email claiming to be from your domain, it queries your SPF record and checks whether the sending server's IP address is authorized. If the IP is not listed, the email fails SPF.

SPF Record Syntax Breakdown

Every SPF record follows this general structure:

v=spf1 [mechanisms] [qualifier]all

The v=spf1 prefix is mandatory and identifies the record as SPF version 1. After the version tag, you list one or more mechanisms that specify authorized senders, followed by a catch-all qualifier that defines the default action for unlisted senders.

SPF Mechanisms Explained

include: — Delegates authorization to another domain's SPF record. Example: include:_spf.google.com authorizes all Google Workspace mail servers. Each include: counts as one DNS lookup toward the 10-lookup limit.

ip4: and ip6: — Authorizes specific IP addresses or CIDR ranges. Example: ip4:198.51.100.0/24. These do not count toward the DNS lookup limit, making them useful for reducing lookup count.

a: — Authorizes the IP addresses returned by an A or AAAA record for a given domain. Example: a:mail.example.com authorizes whatever IP that hostname resolves to.

mx: — Authorizes the IP addresses of your domain's MX servers. Useful when your incoming mail servers also send outbound email.

redirect= — Replaces the entire SPF record with another domain's SPF record. Unlike include:, redirect applies only if no other mechanisms match first.

SPF Qualifier Types

-all (Hard Fail) — Emails from unauthorized servers are rejected. This is the most secure option and recommended for domains with fully verified sender lists.

~all (Soft Fail) — Unauthorized emails are accepted but marked as suspicious. Most domains start here during initial SPF deployment.

?all (Neutral) — No assertion is made about unauthorized senders. This effectively disables SPF enforcement and is not recommended.

Real-World SPF Record Examples

Google Workspace only:
v=spf1 include:_spf.google.com -all

Google Workspace + SendGrid:
v=spf1 include:_spf.google.com include:sendgrid.net -all

Microsoft 365 + Mailchimp + custom IP:
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.50 -all

Keep your SPF record under 10 DNS lookups. If you exceed this limit, the entire SPF check returns a PermError and authentication fails. Use our checker tool to count your current lookups and identify opportunities to consolidate.

Understanding DKIM Records — Keys & Signatures

DKIM (DomainKeys Identified Mail) provides cryptographic proof that an email was sent by an authorized server and that the message body and key headers were not altered during transit. Unlike SPF, which only validates the sending server's IP, DKIM validates the message content itself. This makes DKIM essential for protecting email integrity across forwarding chains, mailing lists, and relay services where SPF alone would fail.

How DKIM Signing Works

When your mail server sends an email, it generates a hash of specified message headers (typically From, To, Subject, Date, and MIME-Version) and the message body. This hash is encrypted using a private key stored securely on the sending server. The encrypted hash, known as the DKIM signature, is added to the email as a DKIM-Signature header.

The receiving server extracts the selector (s=) and domain (d=) values from the DKIM-Signature header, queries DNS for the public key at selector._domainkey.domain.com, decrypts the signature using the public key, and compares it to its own hash of the message. If the hashes match, the email passes DKIM verification.

DKIM Key Types and Sizes

RSA Keys (most common): RSA is the standard cryptographic algorithm for DKIM. The minimum recommended key size is 2048 bits. While 1024-bit keys are still technically valid, they are considered weak and may be flagged by security-conscious receivers. Some providers still default to 1024-bit keys, so verify your key length when running a DKIM check.

Ed25519 Keys (emerging standard): Ed25519 offers stronger security with shorter keys and faster verification. Support is growing but not yet universal. If you use Ed25519, publish both an Ed25519 and an RSA key to ensure compatibility with all receiving servers.

Anatomy of a DKIM DNS Record

A DKIM DNS TXT record contains several tag-value pairs:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhki...

v=DKIM1 — Version identifier (required).

k=rsa — Key type. Defaults to RSA if omitted. Use k=ed25519 for Ed25519 keys.

p= — The base64-encoded public key (required). If this field is empty, the key has been revoked.

t=s — Optional flag that enforces strict alignment, meaning the DKIM domain must exactly match the From domain (no subdomains allowed).

DKIM Verification and Troubleshooting

Common reasons DKIM verification fails include expired or rotated keys where the DNS record was not updated, message body modifications by intermediate mail servers or security gateways, incorrect selector configuration in the sending server, and DNS propagation delays after publishing a new key. Our checker tool validates your DKIM record format and key length, but you should also send test emails and inspect the Authentication-Results header to confirm end-to-end DKIM verification. For a deeper dive into email verification mechanics, read our email verification best practices guide.

Understanding DMARC Policies — none, quarantine, reject

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that ties SPF and DKIM together. While SPF and DKIM verify sender authorization and message integrity respectively, DMARC tells receiving servers what action to take when an email fails these checks. DMARC also introduces the concept of alignment, which requires that the domain used in SPF or DKIM matches the domain in the visible From header.

The Three DMARC Policy Levels

p=none (Monitor Mode): Emails that fail authentication are delivered normally. The receiving server sends DMARC reports to the addresses specified in rua= and ruf= tags. This mode is for observation only and does not protect your domain from spoofing. Use p=none during initial deployment to identify all legitimate sending sources before enforcing a stricter policy.

p=quarantine (Suspicious Mode): Emails that fail authentication are sent to the recipient's spam or junk folder instead of the inbox. This is the intermediate enforcement level that protects recipients while giving you time to resolve any remaining authentication gaps. The pct= tag lets you apply quarantine to a percentage of failing emails (for example, pct=50 quarantines half and delivers the rest normally).

p=reject (Full Enforcement): Emails that fail authentication are blocked entirely by the receiving server. The message is never delivered. This is the strongest protection against domain spoofing and phishing. Google, Yahoo, and Microsoft all recommend p=reject as the ultimate goal for all domains. Once you reach p=reject, unauthorized senders cannot successfully impersonate your domain.

DMARC Alignment: Relaxed vs. Strict

DMARC alignment determines how closely the domains in SPF and DKIM must match the From header domain. Relaxed alignment (aspf=r; adkim=r) allows subdomains to align with the organizational domain. For example, an email from news@marketing.example.com would align with SPF or DKIM for example.com. Strict alignment (aspf=s; adkim=s) requires an exact domain match. Relaxed alignment is the default and is recommended for most organizations because many email services send from subdomains.

DMARC Reporting

Aggregate reports (rua=): XML reports sent daily by receiving servers showing authentication results for all emails from your domain. These reports contain sending IP addresses, authentication pass/fail counts, and the policy applied. They are essential for identifying unauthorized senders and monitoring your authentication health over time.

Forensic reports (ruf=): Detailed reports about individual emails that fail DMARC. These include message headers and sometimes partial message content. Not all receiving servers send forensic reports due to privacy concerns, but those that do provide valuable data for investigating spoofing incidents.

Recommended DMARC Deployment Path

Week 1 to 2: Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Collect and analyze aggregate reports to inventory all legitimate sending sources. Week 3 to 4: Ensure all legitimate sources pass SPF and DKIM. Fix any misconfigurations identified in reports. Week 5 to 6: Move to p=quarantine; pct=25 and gradually increase the percentage. Week 7 and beyond: Move to p=reject; pct=100 for full protection. Continue monitoring reports to catch new sending sources.

Email Authentication Best Practices for 2026

Email authentication requirements have tightened significantly. Google and Yahoo's sender requirements, first introduced in February 2024, now serve as the industry baseline. Any sender that does not meet these standards faces reduced deliverability, spam folder placement, or outright rejection. Here are the current best practices every sender should follow.

Gmail and Yahoo Requirements for Bulk Senders

As of 2024, any domain sending more than 5,000 emails per day to Gmail or Yahoo addresses must have valid SPF and DKIM records, a published DMARC record with at least p=none, one-click unsubscribe headers in marketing emails, and a spam complaint rate below 0.3%. In 2025 and 2026, these requirements have become stricter, with more mailbox providers adopting similar policies. Domains that do not comply see measurable drops in inbox placement rates.

Recommended Setup Order

1. SPF first: Start with SPF because it is the simplest to implement and provides immediate sender authorization. List all your sending services in a single TXT record and use ~all initially.

2. DKIM second: Configure DKIM through each of your email service providers. Most ESPs provide the public key you need to add to DNS. Verify DKIM signing is active by checking outgoing email headers.

3. DMARC third: Publish a DMARC record with p=none after both SPF and DKIM are confirmed working. This ensures you start receiving aggregate reports without risking mail delivery.

4. Enforce progressively: Use DMARC reports to verify all legitimate mail passes authentication, then move from p=none to p=quarantine and finally p=reject. Use our email deliverability checker to monitor the impact of each policy change.

Additional Best Practices

Use 2048-bit DKIM keys: 1024-bit keys are the minimum, but 2048-bit keys provide substantially stronger protection. Rotate keys every 6 to 12 months.

Avoid using ~all permanently: Soft fail (~all) is fine during initial deployment, but you should move to hard fail (-all) once your sender inventory is complete. Soft fail gives receiving servers discretion, which weakens your authentication posture.

Monitor DMARC reports continuously: Do not set and forget. New sending services, infrastructure changes, and third-party integrations can break authentication silently. Monthly reviews at minimum, weekly for high-volume senders.

Authenticate all sending sources: Every service that sends email on your behalf needs to be included in your SPF record and should sign with DKIM. This includes transactional email services, marketing platforms, CRM systems, helpdesk tools, and any SaaS product that sends email using your domain.

Implement BIMI: Brand Indicators for Message Identification displays your brand logo next to authenticated emails in supported inboxes. BIMI requires p=quarantine or p=reject DMARC policy and a Verified Mark Certificate (VMC). It is a visual trust signal that improves open rates and brand recognition.

For programmatic email authentication checks across your entire sending infrastructure, integrate our email verifier API into your monitoring workflows to get automated alerts when authentication records change or break.

Who Needs Email Authentication Checking?

Email authentication checking is not just for IT teams. Anyone who sends email or depends on email deliverability benefits from regular SPF, DKIM, and DMARC validation. Here are the key groups that should be running authentication checks regularly.

Web Developers and DevOps Engineers

Developers who configure transactional email for applications need to verify that SPF records include their sending infrastructure, DKIM keys are properly published, and DMARC policies do not inadvertently block application-generated emails. A single DNS misconfiguration during a deployment can silently break password resets, order confirmations, and other critical transactional messages. Checking authentication records should be part of every infrastructure deployment checklist.

Email Marketers and Campaign Managers

Marketing teams depend on inbox placement to drive conversions. If SPF or DKIM is misconfigured, campaigns land in spam regardless of content quality. Before every major campaign launch, marketers should verify that all sending domains and subdomains pass authentication checks. This is especially important when switching ESPs, adding new sending domains, or onboarding new marketing automation tools. Poor authentication directly reduces open rates, click rates, and revenue.

IT Administrators and Security Teams

IT admins are responsible for the domain's DNS records and overall email security posture. Regular authentication checks help catch unauthorized changes, expired DKIM keys, and incomplete DMARC enforcement. Security teams use DMARC reports to detect spoofing attempts and unauthorized use of the organization's domain. For organizations subject to compliance frameworks like SOC 2, ISO 27001, or PCI DSS, email authentication checking is part of ongoing security monitoring.

Email Deliverability Specialists

Deliverability professionals troubleshoot inbox placement issues for clients and internal teams. A comprehensive email authentication check is always the first diagnostic step because authentication failures are the most common cause of deliverability problems. Deliverability specialists use tools like our SPF DKIM DMARC checker alongside deliverability testing and API-based monitoring to maintain optimal inbox placement across all sending domains.

Small Business Owners

Small businesses often set up email through Google Workspace or Microsoft 365 and never configure authentication records. This leaves their domain vulnerable to spoofing and reduces the deliverability of their legitimate emails. Even if you send only a few hundred emails per month, proper SPF, DKIM, and DMARC configuration ensures your invoices, proposals, and customer communications reach the inbox. Use our free checker to verify your setup takes less than 30 seconds.

SaaS Platform Operators

SaaS platforms that send email on behalf of their customers (such as e-commerce platforms, CRM tools, and marketing automation services) must ensure their sending infrastructure is properly authenticated. Each customer domain needs its own SPF, DKIM, and DMARC configuration. Platform operators should provide self-service authentication verification tools and proactively check customer domain configurations to prevent deliverability issues that generate support tickets and churn.

SPF, DKIM, DMARC Checker FAQ

What is SPF and why do I need it?

SPF (Sender Policy Framework) is a DNS record that specifies which mail servers are authorized to send email on behalf of your domain. Without SPF, spammers can forge your domain in the From address, and receiving servers may reject or spam-folder your legitimate emails.

How do I check my DKIM record?

Enter your domain and DKIM selector in our checker tool. The tool queries your DNS for the DKIM public key record and validates its format, key length (should be 2048-bit minimum), and compatibility with major email providers.

What does a DMARC policy do?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving mail servers what to do when an email fails SPF or DKIM checks. Policies include none (monitor only), quarantine (send to spam), or reject (block entirely). DMARC also provides reporting on authentication failures.

What should my DMARC policy be set to?

Start with p=none to monitor authentication results without affecting delivery. Once you confirm all legitimate email passes SPF and DKIM, move to p=quarantine and eventually p=reject for maximum protection against domain spoofing.

Can I check authentication records for any domain?

Yes, SPF, DKIM, and DMARC records are public DNS records that anyone can query. Our tool checks any domain and provides a detailed report with pass/fail status, record contents, and recommendations for improvement.

How often should I check my email authentication records?

Check your records after any DNS changes, email provider migrations, or when adding new sending services. We recommend a monthly automated check to catch accidental changes or misconfigurations that could affect your email deliverability.

How do I check SPF and DKIM records together?

Enter your domain in our checker tool to check SPF and DKIM simultaneously. The tool queries your DNS for the SPF TXT record on your root domain and probes common DKIM selectors at selector._domainkey.yourdomain.com. Both checks run in parallel and results are displayed together with pass/fail status for each protocol.

What is the difference between SPF, DKIM, and DMARC?

SPF specifies which servers can send email for your domain (sender authorization). DKIM adds a cryptographic signature to verify the email was not altered in transit (message integrity). DMARC ties them together by defining what action to take when emails fail SPF or DKIM checks and provides reporting. All three work together to form a complete email authentication framework.

What happens if I do not have DMARC configured?

Without DMARC, receiving mail servers have no instruction on how to handle emails that fail SPF or DKIM checks. This means spoofed emails using your domain may still be delivered to recipients. You also lose visibility into who is sending email on behalf of your domain since DMARC reporting will not be active.

What SPF record syntax should I use for multiple email providers?

List all providers in a single SPF record using include mechanisms. For example: v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org -all. Never create multiple SPF records as this causes authentication failures. Keep the total DNS lookup count at 10 or fewer.

How do I move from DMARC p=none to p=reject safely?

Start by monitoring DMARC aggregate reports at p=none for 2 to 4 weeks to identify all legitimate senders. Fix any authentication failures. Then move to p=quarantine with pct=25 and gradually increase to pct=100. Monitor for delivery issues. Finally switch to p=reject with pct=25, increase gradually, and set pct=100 once confident all legitimate email passes authentication.

Do Gmail and Yahoo require email authentication in 2026?

Yes. Since February 2024, Gmail and Yahoo require SPF and DKIM for all bulk senders (over 5,000 emails per day) and a published DMARC record with at least p=none. These requirements have become the industry standard, with more mailbox providers adopting similar policies. Non-compliant senders experience reduced inbox placement and increased spam folder delivery.

SPF, DKIM, DMARC Checker — Verify Email Authentication Records