Authentication history · 60 days observed
ruggable.com
Observed from 4 Aug 2026 to 3 Oct 2026. 1 dated move on record, newest first.
Where it stands today
Live lookup, 3 Oct 2026. The same check /check/ruggable.com runs.
- 1worth a look
- 3fine
- 1context
Worth a look
This record authorises nobody at all
There is no include:, ip4: or mx before the all mechanism, so the record says that no host on the internet may send as this domain. That is the correct setting for a domain nobody sends from, and it means every message fails on a domain somebody does.
v=spf1 redirect=cf3962es._spf._d.mim.ec
From Gmail enforces authentication, PTR, TLS and a 0.30 percent spam rateSee what this looks like →
This one needs you
Answer one question: does any campaign leave from this exact domain? If nothing does, this record is right and you are finished. If something does, send yourself one message and read the Authentication-Results header — it will say =fail, and it has been saying so since the record went up.
Looks fine
present with p=quarantine
A policy that actually instructs receivers, which is more than most senders publish.
v=DMARC1; p=quarantine; rua=mailto:5b05787c910f297@rep.dmarcanalyzer.com; ruf=mailto:5b05787c910f297@for.dmarcanalyzer.com; fo=1;
From DMARC p=none is monitoring, not enforcementSee what this looks like →
Looks fine
keys published on 4 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.
google._domainkey (Google Workspace), mandrill._domainkey (Mandrill), s1._domainkey (SendGrid), s2._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=ruggable.com in the Authentication-Results header.
Looks fine
SendGrid is authorised on send.ruggable.com
SendGrid signs mail as this domain, and the root record does not name it — which on its own looks like a mismatch. It is not: send.ruggable.com publishes its own SPF naming SendGrid, and SPF is evaluated against the envelope domain rather than the root. This is the normal setup for bulk mail on a subdomain.
v=spf1 redirect=cf3962es._spf._d.mim.ec
From Gmail enforces authentication, PTR, TLS and a 0.30 percent spam rateSee what this looks like →
Context
MX records present
Where you receive mail says nothing about where you send it. Marketing sends usually leave through a different platform entirely.
gh-mail.ruggable.commxb.mailgun.org, us-smtp-inbound-1.mimecast.com, us-smtp-inbound-2.mimecast.com
What has moved
One entry per day a published record actually changed. Days we looked and found nothing different are counted, not listed.
DMARC record changed.
was: v=DMARC1; p=none; rua=mailto:5b05787c910f297@rep.dmarcanalyzer.com; ruf=mailto:5b05787c910f297@for.dmarcanalyzer.com; fo=1; now: v=DMARC1; p=quarantine; rua=mailto:5b05787c910f297@rep.dmarcanalyzer.com; ruf=mailto:5b05787c910f297@for.dmarcanalyzer.com; fo=1;
First observation — what was already published
SPF published.
v=spf1 redirect=cf3962es._spf._d.mim.ec
DMARC published.
v=DMARC1; p=none; rua=mailto:5b05787c910f297@rep.dmarcanalyzer.com; ruf=mailto:5b05787c910f297@for.dmarcanalyzer.com; fo=1;
DKIM keys on selectors we probe.
google._domainkey (Google Workspace), mandrill._domainkey (Mandrill), s1._domainkey (SendGrid), s2._domainkey (SendGrid)
MX records present.
gh-mail.ruggable.commxa.mailgun.org, gh-mail.ruggable.commxb.mailgun.org, us-smtp-inbound-1.mimecast.com, us-smtp-inbound-2.mimecast.com