Three different questions
Mailbox providers look at the domain in the From address and ask three questions. Is this server allowed to send for that domain? Did the message stay intact after it was signed? What should we do if the first two answers are no? SPF, DKIM, and DMARC are the DNS records that answer those questions. They do not write your copy, choose your list, or measure whether a person opened the mail.
You publish them at your DNS host. InboxMonitor reads them once a day and emails you when a check gets worse. The free plan covers 3 domains and does not ask for a card. The checks are the same ones described below.
SPF: who is allowed to send
SPF is a TXT record on the domain itself, starting with v=spf1. It lists the servers and sending services allowed to send mail that uses that domain. A typical record names each service with include:, sometimes an ip4: or ip6: for a server you run, and ends with ~all or -all. ~all is a soft fail. -all is a hard fail. +all means everyone is allowed, which InboxMonitor treats as a serious mistake and costs 22 points.
Receivers look at the server that handed them the message and walk the SPF record. If the server matches, SPF passes for that hop. If the walk needs more than 10 DNS lookups, the record is treated as a failure even when every include looks legitimate. That limit, and what to do about it, is covered in the guide on too many SPF lookups.
SPF does not, by itself, protect the visible From address. It describes the envelope sender path. A message can pass SPF for one domain and still misalign with the domain the person sees. That is part of why DMARC exists.
DKIM: a signature that should still match
DKIM is a signature added by the sending service. The public half of the key is a TXT record at a name like selector._domainkey.yourdomain. The selector is a label the service chooses. Google, Microsoft, and many cold-email tools each use their own. InboxMonitor looks at a list of common selectors. If you know the real selector, add it on the domain page so the check looks there too.
If the signature matches the public key, the message was not changed in the ways the signature covers, and the signer held the private key. If the record has an empty p= tag, that selector was revoked. InboxMonitor only lowers the score for a revoked selector when no other selector still has a usable key. A key under 1024 bits is a warning. A 1024-bit key is noted, and 2048 is the size worth publishing next time you rotate.
No key at the common selectors does not lower the score when you have not named a custom selector. The check says so, because a private selector name is normal. If you saved selectors and none of them resolve, that does lower the score.
DMARC: what to do when alignment fails
DMARC is a TXT record at _dmarc.yourdomain. It tells receivers what to do when SPF or DKIM fails to align with the domain in the From header. The policy tag is p=. p=none asks them to deliver the mail and, if you published rua=, to send you aggregate reports. p=quarantine asks them to treat failing mail as suspicious, often by filing it in junk. p=reject asks them to reject failing mail.
Alignment means the domain that passed SPF or DKIM is the same as the From domain, or a parent you allowed. A passing SPF result for a different domain does not satisfy DMARC. That is the gap people hit when a tool sends through its own domain and the From says yours.
InboxMonitor treats a missing DMARC record as critical. It treats p=none as a warning: useful while you read reports, weak as a forever policy on a domain you send from. A record with no rua= address costs a small number of points because you will not see the reports. Moving from p=none to quarantine has its own guide, because doing it before mail aligns can junk mail you still want.
What these records do not do
They do not guarantee the inbox. A domain can be Healthy and still land in spam because of the list, the content, the volume, or a blocklist on an address these checks did not query. InboxMonitor's blocklist check, by default, asks PSBL and 0spam about the sending addresses it can see. A timeout is not a clean result and it is not a listing.
They also do not replace the MX record. MX says where replies and bounces should go. A sending domain with no MX loses the bounce path. InboxMonitor flags that as a warning. If the domain should never receive mail, a null MX is a deliberate choice, not an accident.
Set the three records so they match the tools that actually send. Then let a daily check tell you when someone edits DNS or a provider changes a selector. That is the job of InboxMonitor. If you want the records written out for one domain, InboxRescue Audit is a one-time report. It does not promise placement or delisting.