Why Your Contact Form Isn't Sending Emails: A Complete Debugging Checklist

This sounds trivial. It accounts for about 30% of "my contact form isn't working" reports I see. The email did send, did arrive, and is sitting in your Gmail spam or Outlook Junk folder right now.

Where to look in each major provider

• Gmail: Left sidebar → "More" → Spam. Also check Promotions and Updates tabs — form notifications occasionally end up there.
• Outlook / Hotmail: Left sidebar → Junk Email.
• Yahoo Mail: Left sidebar → Spam.
• Apple Mail (iCloud): Mailboxes → Junk.
• Self-hosted / corporate email: Ask your IT team to check the gateway quarantine — Mimecast, Proofpoint, and Microsoft Defender all silently quarantine emails without notifying recipients.

If you find it there, your technical setup is fine. Your problem is sender reputation or authentication. Skip to Step 4 (fix SPF/DKIM/DMARC).

If you don't find it in spam after a thorough search across all folders and tabs, continue to Step 2.

Before debugging email delivery, confirm the form submission reached the form-handling service at all. A submission might silently fail without the form even pinging the backend if:

• CORS is blocking the POST (browser console will show a CORS error in red).
• The form's action attribute has a typo or expired URL.
• JavaScript is intercepting the submit and failing silently.
• Your backend is rate-limiting you or your IP.

How to verify

If you use a form backend service (Formspree, FormsList, Getform): log into the dashboard and look at the Submissions tab. If your test submission appears there, the form-to-backend hop worked and the problem is the backend-to-email hop. Skip to Step 3.

If you self-host: open browser DevTools → Network tab → submit the form → look at the POST request. You're checking for:

• HTTP status (should be 200 or 201; 4xx or 5xx is the problem)
• Response body (look for error messages)
• Request payload (confirm the form data is actually being sent)

If the POST never fires or shows an error, the problem is in your frontend code, not your email setup. Common causes: preventDefault() blocking the submit without firing your custom handler, missing fetch() call, or a CSRF token mismatch.

This is the #1 cause of "submission shows in dashboard but no email arrives" — the backend tried to send but the email provider rejected it, and the backend silently swallowed the error.

I see this constantly because of how Promise-based code is typically written:

// BAD — the .catch() swallows the error
sendEmail(recipient, subject, body).catch(console.error);

// The submission saves successfully, the response returns 200,
// but the email failed and nobody knows.

How to check (per provider)

• Resend: Dashboard → Emails tab. Shows every send attempt with delivered/bounced/failed status and the exact error message.
• SendGrid: Activity Feed shows delivery status per email. Filter by "Dropped" or "Bounced" to find failures.
• Postmark: Activity tab shows the same — look for Hard Bounce, Soft Bounce, or Spam Complaint statuses.
• Mailgun: Sending → Logs. Failed sends appear with explicit error messages.
• AWS SES: CloudWatch Logs for the function that calls SES — most teams forget to set this up.
• Self-hosted SMTP (Postfix, etc.): Check /var/log/mail.log or /var/log/maillog.

Common errors you'll see in these logs:

• "403 Forbidden — domain not verified" — your sending domain hasn't been verified with the email provider. Fix in Step 4.
• "550 Mailbox unavailable" — the recipient address bounces. Fix the typo.
• "554 Message rejected: spam content" — recipient server flagged the message. Often fixable by tweaking subject line or adding plaintext alternative.
• "5.7.26 This mail is unauthenticated" — Gmail-specific. Means SPF or DKIM failed. Fix in Step 4.

If you see any of these in your logs, you've found your bug. If your logs are empty, the email never even tried to send — go back to Step 2 to verify the submission reached the backend.

If your emails are sending but landing in spam, this is your bug. Modern email providers reject or junk-folder any email whose sender domain doesn't authenticate properly. Gmail tightened this in 2024 — emails without SPF + DKIM + DMARC simply don't reach Gmail inboxes anymore for bulk senders.

What each record does (in 30 seconds)

• SPF (Sender Policy Framework): A DNS TXT record listing which servers are allowed to send email "from" your domain. Without it, receivers can't tell if the email is legitimate or spoofed.
• DKIM (DomainKeys Identified Mail): A cryptographic signature on each outgoing email, verifiable via a public key in your DNS. Proves the email wasn't tampered with in transit.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): Tells receivers what to do if SPF or DKIM fails (reject / quarantine / none) and where to send failure reports.

Receivers (Gmail, Outlook, Yahoo) check all three. If any is missing or fails, the email gets junk-foldered or outright rejected.

How to fix it

The exact records depend on your email provider. Here are the most common setups:

If sending via Resend

Go to resend.com/domains → Add your domain → Resend gives you 3 records to add to your DNS:

1. TXT record at "resend._domainkey" — for DKIM
2. MX record at "send" — for bounce handling
3. TXT record at "send" — for SPF
4. (Recommended) TXT record at "_dmarc" — for DMARC policy

If sending via SendGrid

SendGrid → Settings → Sender Authentication → Domain Authentication. They provide 3 CNAME records for DKIM and an SPF record.

If self-hosting

You need:

• An SPF TXT record: v=spf1 ip4:YOUR_SERVER_IP -all
• A DKIM TXT record: generate keys with opendkim-genkey, publish the public key as TXT
• A DMARC TXT record: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com (start with p=none to monitor, escalate to p=quarantine or p=reject later)

How to verify the records work

Use mail-tester.com — send a test email to the address it generates and it returns a deliverability score (out of 10) with detailed SPF/DKIM/DMARC results. Aim for 9/10 or better. Below 7 means real deliverability problems.

You can also run dig TXT yourdomain.com from a terminal to see what your DNS actually serves vs. what you think you configured.

If your DNS records are perfect but emails still don't arrive, your domain or sending IP may be on an email blocklist (also called a "blackhole list" or RBL).

Free check tools:

• MXToolbox Blacklist Check — checks 100+ major blocklists at once
• multirbl.valli.org — even more comprehensive
• Spamhaus lookup — Spamhaus is the most influential of the blocklists

If you find your domain or IP listed:

• For shared infrastructure (Resend, SendGrid, etc.) — contact the email provider's support. They handle blocklist negotiations as part of their service.
• For your own SMTP server — submit removal requests directly to each blocklist (each has its own form). Note that many blocklists won't remove you until you fix the issue that caused the listing (open relay, compromised account, etc.).

Prevent re-listing: enforce strong DMARC (p=quarantine or p=reject), implement rate limiting on outbound email, monitor bounce rates (high bounce rates trigger listings).

If the email is leaving your server cleanly but never appears, the problem might be on the recipient's side, not yours.

Common recipient-side blockers

• Corporate email gateway (Mimecast, Proofpoint, Microsoft Defender): These quarantine "unknown sender" emails by default. The recipient never sees them in their inbox OR spam — they sit in a gateway quarantine that only IT can release. Ask your IT team to whitelist your sender domain.
• Email forwarding chains: If the recipient's address forwards to another address (e.g., support@yourdomain.com → founder@gmail.com), DMARC enforcement can drop the forwarded email. The fix is to enable ARC (Authenticated Received Chain) headers or stop forwarding through DMARC-strict domains.
• Mailbox over quota: The recipient's inbox is full. Rare with Gmail's 15GB but common with corporate setups.
• Recipient blocklisted you: A previous email got marked as spam by the recipient, and their provider is now blocking you specifically.

To diagnose: send a test email to a different address (yourself at a personal Gmail, for instance). If it arrives there but not at the original recipient, the problem is on their end.

Even with perfect authentication, certain content patterns trigger spam filters. If your notification emails consistently land in Promotions or Spam, the content might be the issue.

Common spam-trigger patterns in form notifications

• All-caps subject lines ("NEW SUBMISSION!!!")
• Excessive punctuation in subject (lots of !!! or ???)
• Spam-trigger words in subject: "free", "winner", "urgent", "click here", "guaranteed"
• HTML-only emails without plaintext alternative — modern email best practice is multipart with both
• Images without alt text, or links to image hosts unrelated to your domain
• "From" name mismatch with from-address domain — e.g., from: "Acme Corp" but the email is from noreply@notify-me-now.xyz
• Very short body text — emails that are just "New submission" with no other content look bot-generated

Test your notification content at mail-tester.com — the report flags specific content issues.

A solid form-notification email template

From: "[Form Name] via FormsList" <noreply@yourdomain.com>
Subject: New submission on Contact Form

Hi,

You received a new submission to your "Contact Form".

Name: Jane Smith
Email: jane@example.com
Message: I'm interested in your services...

View full submission: https://formslist.com/dashboard/...

Clean subject, named "from" address with verified domain, plaintext-friendly structure. Lands in inbox.

If you use Gmail and your notification emails arrive but show up in Promotions, Updates, or Social — not Inbox — this is a different problem from spam folder. Gmail isn't classifying your email as spam; it's classifying it as marketing.

What triggers the Promotions tab

• Heavy HTML formatting with images, buttons, colors
• Bulk-send patterns: sending many emails per day from the same domain
• Unsubscribe link presence (Gmail interprets this as marketing)
• "Notification" / "alert" / "update" in subject line

How to escape Promotions

• Send plaintext or minimal-HTML emails. A form notification doesn't need 800px of CSS-styled HTML — a clean text-based email reads better and avoids Promotions classification.
• Remove or minimize images.
• Don't include unsubscribe links on transactional notifications (only required by CAN-SPAM/GDPR for marketing emails).
• Send from a real-looking person/role: "Vaibhav from FormsList" rather than "Notifications".
• Ask recipients to drag the email to Inbox the first time. Gmail's algorithm learns from this.

FormsList notification emails are designed plaintext-style for this reason — minimal HTML, no marketing-looking buttons or unsubscribe links on transactional sends.

If you've worked through steps 1–8 and still have issues, run a structured deliverability test. This gives you a numeric score and a specific list of issues to fix.

Recommended tools

• mail-tester.com — free, no signup. Generates a unique email address; you send a test email to it; it returns a 10-point score with breakdown. Aim for 9+/10. Below 7 means real problems.
• GMass Inbox Test — sends a test email to seed inboxes at Gmail, Outlook, Yahoo, AOL and reports where each landed.
• GlockApps (paid) — most comprehensive deliverability monitoring; useful if you send to a lot of recipients.
• Google Postmaster Tools — free, official Gmail tool. Shows your domain's reputation, spam rate, and authentication results as Gmail sees you. Set this up if you send any volume to Gmail.

Address each specific issue these tools flag in priority order. Most "my emails go to spam" problems get resolved within an hour of running mail-tester.com and fixing what it reports.

Email deliverability is genuinely one of the hardest problems in modern web infrastructure. You can spend weeks tuning your own SMTP setup, fighting Gmail's spam filters, monitoring blocklists, and watching your bounce rates — and a single misconfiguration can blow up your sender reputation for months.

This is why managed email infrastructure (Resend, SendGrid, Postmark, Mailgun, Amazon SES) exists. They handle:

• SPF, DKIM, DMARC setup (they guide you through it)
• Sender reputation management (they own the IP, they protect it)
• Blocklist negotiations (their abuse team talks to Spamhaus)
• Bounce handling, complaint feedback loops, and delivery analytics
• The compliance side (CAN-SPAM, GDPR DPAs, etc.)

If you're a developer running a form on your portfolio site, the right answer is to use a form backend service that already integrates with one of these (FormsList uses Resend, for example) and inherit their deliverability work. You'll get inbox placement on day one without touching DNS beyond initial setup.

If you're an engineering team building forms into a product with thousands of customers each sending notifications, you'll still want to terminate at one of these services — but you'll need someone responsible for monitoring the reputation dashboard weekly.

The wrong answer for almost everyone in 2026 is "let me roll my own SMTP". Don't.

Save this list. Work top-to-bottom the next time emails aren't arriving:

1. Check spam folders — Gmail Spam, Promotions, Updates; Outlook Junk; corporate gateway quarantine.
2. Verify the submission reached your backend — dashboard or DevTools Network tab.
3. Check your email provider's logs — Resend, SendGrid, Mailgun all expose detailed send/bounce/fail logs.
4. Fix SPF, DKIM, DMARC on your sending domain. Verify with mail-tester.com.
5. Check blocklists at mxtoolbox.com/blacklists.aspx.
6. Diagnose recipient-side issues — corporate gateways, forwarding chains, mailbox quota.
7. Audit email content — subject lines, HTML/text ratio, spam-trigger words.
8. Handle the Gmail Promotions tab separately from spam — different fix.
9. Run mail-tester.com for a structured deliverability score.

If you're still stuck after working through all nine, the problem is almost certainly worth offloading to a managed form backend that has solved deliverability for you.