Nothing here is yours.
One finding is shared with your sending platform. The mechanical half is done and the judgement is still yours.
19 DNS lookups23 blocklists askedno entriesno score, ever
read from DNS, quoted verbatim
- SPF
- -all
- DMARC
- p=reject
- DKIM
- 3 selectors
- BIMI
- published
- MX
- receiving
- LISTS
- 23 asked
Who sends as you
4 Aug 2026 · no score, no grade, nothing inferred
Who this domain authorises
Your sender list is held by Proofpoint
include:%{ir}.%{v}.%{d}.spf.has.pphosted.com
The record is built from SPF macros, so the senders are resolved per message at delivery time and are genuinely not readable from DNS — not by us, and not by any other checker that tells you it expanded your SPF. Whoever administers Proofpoint holds the answer to which platforms may send as you; this page can only report what your own record says.
SendGrid signs your mail — and your SPF does not list it
- s1._domainkeyDKIM key present
- s2._domainkeyDKIM key present
2 of SendGrid’s own selectors carry live keys, which is a setup somebody completed — not a selector collision. Your SPF names somebody else, so this mail passes DMARC on DKIM alignment alone.
Keys are also published on selectors belonging to Mandrill, and your SPF does not authorise it. Selectors like mandrill._domainkey are short enough to collide, so this is worth checking and is not worth believing on its own.
This is what your DNS authorises, not proof of what you send. A domain can authorise a platform it stopped paying for two years ago, and it can carry live keys for a platform it never authorised, which is the reverse and the more expensive of the two. Only a real message names the address that actually sent your campaign.
Whose job each one is
- 3fine
- 3context
Looks fine
present, ending -all
Hard fail. The strictest setting and the right one once you are confident every sender is listed.
v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com -allLooks fine
present with p=reject
A policy that actually instructs receivers, which is more than most senders publish.
v=DMARC1; p=reject; rua=mailto:dmarc_rua@emaildefense.proofpoint.com,mailto:booking@dmarc.postmastery.eu; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com
From DMARC p=none is monitoring, not enforcementSee what this looks like →
Looks fine
keys published on 3 selectors
A key existing is not the same as working. Read a real received header and check the d= value matches your before you call this done.
mandrill._domainkey (Mandrill), s2._domainkey (SendGrid), s1._domainkey (SendGrid)
From DKIM passing is not DKIM alignedSee what this looks like →
Part platform, part you
The key is your platform's to publish and it has. Whether it signs the domain in your is yours to confirm, and cannot show it — send one campaign to yourself and look for =pass header.d=booking.com in the Authentication-Results header.
Context
SendGrid signs your mail, and your cannot be read to confirm it
2 of SendGrid's selectors carry live keys on this domain, so SendGrid is signing mail as you. Whether your authorises it is not answerable by reading . Your record uses SPF macros (Proofpoint), so the authorised senders are resolved per message from the connecting IP and are never published as a list. No checker can settle it from DNS, including this one — anyone who tells you this record does or does not list SendGrid is guessing.
v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com -allFrom Gmail enforces authentication, PTR, TLS and a 0.30 percent spam rateSee what this looks like →
Good to know — nothing to fix
Send one real campaign through SendGrid and read the Authentication-Results header on what arrives. That header is the only place this question gets answered, because it is the receiver evaluating the macro against the real .
Context
record published
Your logo can appear in supporting clients, which needs at quarantine or reject.
Context
MX records present
Where you receive mail says nothing about where you send it. Marketing sends usually leave through a different platform entirely.
mxa-0032a201.gslb.pphosted.com, mxb-0032a201.gslb.pphosted.com
Blocklists
Nothing has an entry for you.
23 lists asked0 with an entry1 could not be asked
booking.com is not on any of the 23 lists that answered us today. That is the whole result — there is no score, and a clean answer is allowed to be short.
Which lists, and which would not answer
- SpamCopanswered
- PSBLanswered
- Mailspikeanswered
- Spam Eating Monkeyanswered
- blocklist.deanswered
- 0SPAManswered
- InterServeranswered
- SPFBLanswered
- GBUdb Truncateanswered
- s5h.netanswered
- ZapBLanswered
- SWINOGanswered
- Kemptanswered
- Anonmailsanswered
- Fabelanswered
- NoSolicitadoanswered
- Schulteanswered
- JIPPGanswered
- UCEPROTECT Level 1answered
- UCEPROTECT Level 2answered
- UCEPROTECT Level 3answered
- Backscattereranswered
- SEM Backscatteranswered
- URIBLdeclined the query
Each of these answered an entry it is required to publish, and one it is required not to, before we believed anything it said about you. A list that fails either is reported as unanswered rather than as clean — because a blocklist that declines to reply looks exactly like one giving you the all-clear. How we choose them.
Putting this in a client report? Embed a live, dated badge that re-checks itself.
Watch this domain
One email if authentication DNS for booking.com actually changes. Same list as rule alerts — one inbox, one promise.