Will fixing SPF, DKIM and DMARC stop emails going to spam?

It can resolve authentication failures, but it cannot guarantee inbox placement. Sending reputation, complaints, content and the recipient’s filters still matter. A DNS check cannot tell you where a particular message was delivered.

Is a DMARC policy of p=none an error?

No. It is a valid monitoring policy. Whether it is suitable depends on your goal and the requirements that apply to your sending. Check your legitimate senders and alignment before moving to a stricter policy.

How does DMARC protect my domain from impersonation?

p=none provides reporting and visibility but does not ask receivers to block failing messages. Once every legitimate sender consistently passes aligned SPF or DKIM, p=quarantine asks receivers to treat failures as suspicious, while p=reject provides the strongest enforcement against unauthorised use of your exact From domain. Roll out gradually when needed. DMARC does not stop attackers registering a similar-looking domain and does not guarantee inbox placement.

Can you check DKIM with only a domain name?

Not comprehensively. DKIM keys are published under selectors chosen by sending services. A reliable lookup needs the selector and signing domain. Verifying a signature also needs the original message.

What is BIMI, and will it make messages look more trustworthy?

BIMI is a DNS-published brand indicator: compatible mailbox providers may show your logo beside authenticated messages after their own DMARC, reputation and certificate checks. It can improve brand recognition and make legitimate messages easier to recognise, but it does not change delivery or guarantee that a provider will show the logo. A BIMI setup needs a correctly authenticated sending domain, a suitable SVG logo and, for many providers, a VMC or CMC.

Should I paste a new SPF record over the old one?

First inventory all services that send from the affected domain. A replacement that authorises one service but removes another can cause new failures. Preserve the previous record so you can review or roll back the change.

What exactly do I receive in the $5 Fix Pack?

You receive a private, downloadable package for one confirmed issue: a diagnostic-message check, the DNS baseline we checked, the supported scope, proposed changes or required provider inputs, safe application guidance, rollback context and three configuration rechecks within seven days. The package then gives you a direct link to request the complete scoped fix from an infrastructure engineer if you prefer not to apply it yourself. The pack is tied to your domain and finding; it is not a generic DNS template.

Will MailFixIt change my DNS automatically?

The first Fix Pack gives you the proposed records and provider-specific instructions. You can apply the changes in your own DNS account, or request our assistance if you grant temporary, least-privilege access to the relevant DNS zone. Automatic unattended DNS changes are not part of this offer.

How do payment and package delivery work?

We recheck the selected issue before opening PayPal checkout, so you do not pay for a stale or unsupported scope. After the one-time $5 payment is verified, we prepare the private Fix Pack and open its recovery page. Keep that link private: anyone who has it can access the package. If preparation takes longer, the page shows progress and refreshes automatically.

How should I provide DNS access for assistance?

Use your DNS provider’s delegated user or API token, limited to the relevant zone and DNS-record changes. Do not share your registrar password, account-wide credentials or a token with unrelated permissions. Grant access only after the package scope is confirmed, and revoke or delete the delegated access as soon as the changes are complete.

SPF · DKIM · DMARC · BIMI · PTR

Find why your email is failing. Fix it safely.

Check the DNS behind bounced, rejected and spam-folder email delivery. Find what is actually wrong - and what to fix - without changing anything.

Check my email domainFree · No signup · readonly DNS check

No login for the free checkNo subscription for the Fix PackNo broad DNS access required

Check your email domain configuration

Enter the domain you send email from. We inspect its public MX, SPF, DKIM, DMARC, BIMI and reverse-DNS configuration. Add a sending IP to check its SpamCop listing, PTR, forward-confirmed reverse DNS and origin ASN. A DKIM selector or headers from a problem message can provide more evidence. Nothing is changed, and no account is required.

DomainEnter only the domain — no URL, email address or port.

Paid Fix Pack step 0: send a new message from the affected mail domain to test@mailfixit.io so we can inspect its received SPF, DKIM and delivery-path headers.

Add message details for a deeper check (optional)

DKIM selectorUsually the s= value in the DKIM-Signature header. Find it in your mail provider's setup instructions or in your DNS zone, for example: SELECTOR._domainkey TXT "v=DKIM1"

DKIM signing domainThe d= value; do not enter a provider name unless it is the actual signing domain.

Sending IP addressOptionally, enter the public IP that sends your mail (usually, your web-host or egress of your cluster). If blank, MailFixIt checks up to the first two explicit ip4 addresses in SPF.

Problem message headers (i.e. from Spam/Junk folder)Optional. In your mail client, use View Headers or View Source. Paste headers only; remove the message body and personal content before sharing.

Bounce or rejection textOptional unless the selected diagnostic scenario requires it. You can paste a line from your SMTP server log with the error code, for example: 550 5.7.26 Unauthenticated email from example.com is not accepted due to the domain's DMARC policy.

Envelope sender (MAIL FROM) domain

Visible From domain

Expected receiving provider Choose Other for a provider without provider-specific MX matching.

Should this domain receive email?

Expected provider DNS recordEnter one exact provider-issued record. Do not guess a target.

Amazon SES region Choose the AWS Region used by the SES identity.

SES MAIL FROM domain

SES behavior on MX failureCopy the configured SES fallback behavior; do not guess.

Free check. No made-up "deliverability score". We show what passed, what failed, and what DNS alone cannot know.

What the email DNS checker examines.

Each record answers a different email authentication or sender-identity question. We show the evidence without turning it into a misleading score.

SPF

SPF: which servers can send?

SPF lets a receiving server check whether an IP address is authorised to send email for the envelope sender domain. That domain may differ from the visible From address.

Check for more than one SPF record at the same DNS name, missing sending services and too many DNS lookups during evaluation. Several unrelated TXT records are normal; multiple records beginning with v=spf1 are the problem.

Keep a list of legitimate senders before merging or replacing an SPF record.

DKIM

DKIM: is the message signed?

DKIM uses a cryptographic email signature and a public key published in DNS. Your sending service creates the signature; publishing a DNS record alone does not enable signing.

A check needs the signing domain and selector. Find d= and s= in a message's DKIM-Signature header, or use the values supplied by your email provider.

An unknown selector means DKIM has not been checked. It does not prove DKIM is missing.

DMARC

DMARC: does the sender identity align?

DMARC alignment checks whether the visible From domain aligns with a domain that passes SPF or DKIM. A message can pass SPF for another domain and still fail DMARC.

Look up the record at _dmarc.yourdomain.com. A monitoring policy of p=none is valid. Moving straight to p=reject can disrupt legitimate mail if the senders are not ready.

Domain Impersonation Protection: use p=none to monitor, p=quarantine when aligned legitimate mail is stable, and p=reject only after every real sender is verified.

PTR

PTR: does the sending IP have valid reverse DNS?

PTR maps a public sending IP to a hostname. Valid forward-confirmed reverse DNS also requires that hostname's A or AAAA record to contain the original IP.

Enter the actual sending IP when possible. If it is omitted, the checker can use up to two explicit ip4 host addresses from SPF, but it never samples an SPF network range.

The hosting or network provider that owns the IP normally controls its PTR record.

BIMI

BIMI: can inboxes consider your brand logo?

BIMI lets a sending domain publish a logo reference in DNS for supporting mailbox interfaces to consider after the message passes the provider's authentication requirements.

It is optional. A BIMI record normally lives at default._bimi.yourdomain.com and references a hosted SVG logo; some providers also require a VMC or CMC.

BIMI can improve brand recognition in compatible inboxes, but it does not guarantee logo display or inbox placement.

IP reputation

Sending IP reputation: is the source publicly listed?

MailFixIt checks the supplied sending IP against SpamCop and shows its PTR, forward-confirmed reverse DNS, and origin network. A clean result is useful evidence, but it does not prove that Gmail, Microsoft, Yahoo, or another provider trusts the IP.

You can check your IP reputation independently with Spamhaus, SpamCop, SpamRATS Spam and NoPtr, BarracudaCentral, Cisco Talos, AbuseIPDB, and VirusTotal. Each service provides an independent signal and applies its own access and usage terms.

Use the actual public IP from the rejection or sending log. Do not substitute your website IP unless it sends the mail.

Authentication is one part of delivery. Reputation, complaints, message content and recipient filtering also affect where an email lands.

Common email authentication errors and where to start.

The same symptom can have different causes. Start with the DNS and message evidence instead of replacing records blindly.

What you see	Where to start
Multiple SPF records	Identify every authorised sender. Build one valid SPF record for that DNS name without dropping services you still use.
SPF permerror	Read the full error. Check syntax, duplicate SPF records and the lookup limit before deciding on a fix.
DKIM record not found	Confirm the provider's selector and signing domain. A lookup using the wrong selector cannot establish whether DKIM is configured.
DMARC fails, SPF passes	Compare the envelope sender domain with the visible From domain. Also check whether an aligned DKIM signature passes.
Gmail error 5.7.26	Read the complete bounce: this code covers authentication and policy failures. Check the specific reason Google reports and the affected sender.