Email authentication for paypal.com

SPFValid, with warnings

DKIM2 keys found

DMARCp=reject

SPF (Sender Policy Framework)

9/10 DNS lookups

v=spf1 include:pp._spf.paypal.com include:3ph1._spf.paypal.com include:3ph2._spf.paypal.com include:3ph3._spf.paypal.com include:3ph4._spf.paypal.com include:sendgrid.net include:aspmx.pardot.com ~all

The record uses 9 of the 10 allowed DNS lookups. You are close to the limit.

DKIM (DomainKeys Identified Mail)

Selector s1 (via CNAME s1.domainkey.u2325424.wl175.sendgrid.net)

k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxbgrZ8NI+r1z/S4RHUWdMmwmN+JGEY9Blcd1cqhocyKq+4qzU5TDXX4gKIZ2Apq3tTdA/a5hNEE4bPyhJAHFA0/x7Xhg//F4+iLwAB766QJ10Yjv7nQIqvzMmMpLctr5FjgnclGvPUgow3ofUpnmxyr1s9fR2JdvrRzXtwvuvbDV8j98iuIGYgcTcmQwJHH3HcGuxYOc57YZBNPUQbd5fcR5hcpbi+rWeT/SlNCCLNLP4gmXVg7lPc37Yo3CG5gpAsTAf/4RIxb22aL2xW596h/Hi1EebekpqF1dWogRs7x2JK1JYQaVIJEYNSuv5nqLR6FA1SUmB1375JL4pTXS6…

Selector s2 (via CNAME s2.domainkey.u2048429.wl180.sendgrid.net)

k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMTLst9tYk0BVG2VmtfH+pSW9SYaffk4Z3wx361Z2P8Knyh+UNT6EWgdLfhz35K2hD04HMNy+wQqNiN7EFDmUUiqoJ69Z2d4JKNfNWXoKubJFrTRHdKVl7o17yN/Pw6N/O5wqxqe0pISJjglebwjwX4JpTQZ6wHzQhGu5++JDP2QIDAQAB

DMARC

v=DMARC1; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email

Policy (p)

reject

Subdomain policy (sp)

same as p

Aggregate reports (rua)

mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email

Percentage (pct)

100%

Alignment

DKIM: R, SPF: R (R = relaxed, S = strict)

DMARC is enforced with p=reject and reporting enabled.

Why SPF, DKIM and DMARC matter

Email was designed without sender verification, so anyone can put your domain in the "From" line. Three DNS-based standards fix that. Since February 2024, Google and Yahoo have required them from bulk senders, and missing records are now a common reason legitimate mail lands in spam.

SPF lists the servers allowed to send mail for your domain, in a TXT record starting with v=spf1.
DKIM adds a cryptographic signature to each message; receivers verify it with a public key published at selector._domainkey.yourdomain.
DMARC (at _dmarc.yourdomain) tells receivers what to do when SPF and DKIM fail to align with the From domain (none, quarantine or reject) and where to send reports.

What this checker tests

SPF exists, there is only one record, it ends in ~all or -all (never +all), and the total number of DNS lookups including nested include: mechanisms stays within the RFC 7208 limit of 10.
DKIM keys on the selector you supply, or on a dozen common selectors used by Google Workspace, Microsoft 365 and popular sending services.
DMARC exists, has a valid policy, applies to 100% of mail and sends aggregate reports so you can see who is sending as you.

Example records

example.com.         TXT  "v=spf1 include:_spf.example.net ip4:192.0.2.0/24 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s"
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

Recommended rollout

Publish SPF covering every service that sends for you, ending with ~all.
Turn on DKIM signing in each provider.
Publish DMARC with p=none and an rua address, and review reports for two to four weeks.
Move to p=quarantine, then p=reject, once all legitimate mail passes.

Full walkthrough: SPF, DKIM and DMARC explained.

Frequently asked questions

Should I use ~all or -all?

With DMARC in place, either works; DMARC decides the outcome. ~all is the safer starting point; -all is stricter once you are confident every sender is listed.

What does "too many DNS lookups" mean?

Each include, a, mx, exists and redirect costs a lookup, including those inside included records. Over 10, SPF fails for everyone. Remove unused services or replace includes with ip4/ip6 ranges.

Do parked domains need these records?

Yes. Protect domains that never send email with v=spf1 -all and v=DMARC1; p=reject.

SPF & DMARC Checker