Reference
These DNS-based standards help receivers decide whether mail claiming to be from your domain is legitimate, suspicious, or should be blocked.
SPF
RFC 7208 defines SPF as a way for domain owners to publish which hosts are authorized to use their domain names in SMTP MAIL FROM or HELO identities.
SPF answers, "Is this sending server allowed to send for this domain?" Speedmarc helps reveal which SPF domains and source IPs are actually showing up in DMARC reports.
example.com. 3600 IN TXT "v=spf1 include:_spf.example.net ~all"DKIM
RFC 6376 describes DKIM as a signature system that lets the owner of a signing domain claim responsibility for a message using a cryptographic signature and a public key retrieved from DNS.
DKIM answers, "Was this message signed by a domain that is willing to stand behind it?" Speedmarc tracks DKIM domains and selectors so stale or unexpected keys are easier to review.
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."DMARC
RFC 7489 defines DMARC as a scalable way for mail-originating organizations to express domain-level policies for validation, disposition, and reporting.
DMARC answers, "What should receivers do when mail fails authentication, and where should reports go?" Speedmarc turns those reports into a practical inventory so you can move toward stronger policy with better context.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"Large mailbox providers increasingly expect domains to authenticate mail properly. Correct SPF, DKIM, and DMARC records reduce spoofing risk and help legitimate mail keep a stronger reputation.
Speedmarc starts with the safest first step: understand observed sending activity before changing policy.