Direct answer: Inquiry emails usually land in spam not because the form is broken, but because the sending domain lacks SPF/DKIM/DMARC, the From domain is not aligned, the form spoofs the visitor's address, or DNS was not updated after a vendor change. Accept authentication, alignment, inbox placement and bounce tracking—not just "submit succeeded".
This guide is for marketing, export/sales, IT/operations, website vendors and mailbox providers at Changzhou manufacturers. It covers inquiry-form notifications, auto-replies and corporate-domain email deliverability and authentication acceptance. Information is current to 31 October 2026. It is public standards, platform documentation and project method, not email-system or legal advice; DNS, mailbox, vendor and compliance details are confirmed case by case.
SPF says who may send for you; DKIM says the message was not altered; DMARC says what happens on failure and whether domains align. Send form notifications from your own domain and put the visitor in Reply-To; start DMARC at none, then ramp to quarantine/reject.
Why does "form submitted" still mean spam?
"Submitted" only means the data was stored. The email may be spam-filtered, bounced or never sent. Sending-domain authentication, From alignment, form sending method and vendor configuration all affect delivery.
The inquiry chain is usually: visitor submits → website/form service notifies sales → auto-reply to visitor → sales replies. Any link can fail: a third-party form service is not in SPF; From is set to the visitor's address and fails SPF/DMARC; the domain lacks DKIM; the DMARC record is missing or too strict; the sending IP has a poor reputation; the sales mailbox is full or bouncing. "Submit succeeded" only means front-end/back-end received the data, not that the email reached the sales inbox.
| Stage | Possible failure | Symptom | Check first |
|---|---|---|---|
| Form submit | API/validation/spam blocking | Error/no record | Form logs/API |
| Website sending | SMTP failure/authorisation/quota | No notice/delay | Send log/bounce |
| Domain authentication | SPF/DKIM/DMARC missing/misaligned | Spam/rejection | DNS/headers |
| Recipient | Spam rules/blocklist/full mailbox | Bounce/spam folder | Bounce code/inbox |
| Reply path | Wrong Reply-To/auto-reply loop | Visitor gets no reply | Reply test |
The chain split is editorial; sending, bounce and spam decisions follow mailbox/recipient rules.
What do SPF, DKIM and DMARC each do?
SPF authorises sending IPs/servers, DKIM signs the message, DMARC sets failure handling and requires domain alignment. They solve different problems; configuring only one is not enough.
SPF (RFC 7208) publishes in DNS which servers may send for the domain; the recipient checks the sending IP. DKIM (RFC 6376) signs the message with a domain private key; the recipient verifies with a public key in DNS that the message was not altered. DMARC (RFC 7489) builds on SPF/DKIM, requires the SPF or DKIM domain to align with the From header domain, tells receivers what to do on failure (none/quarantine/reject), and collects aggregate/failure reports. SPF alone breaks on forwarding/third-party senders; DKIM alone does not stop unauthorised senders; without DMARC, spoofing lacks policy and visibility.
| Mechanism | Solves | DNS/implementation | Does not solve |
|---|---|---|---|
| SPF | Which servers may send for the domain | Domain TXT: v=spf1 ... | Message content; forwarding breaks it |
| DKIM | Signature that the message was not altered | Selector TXT public key + private signing | Does not authorise IPs or set failure policy |
| DMARC | Alignment + failure policy + reports | _dmarc TXT: v=DMARC1; p=... | Not a spam filter; needs SPF/DKIM |
Definitions follow RFC 7208, RFC 6376 and RFC 7489; implementation follows DNS/mailbox/form-vendor docs.
How should DNS records be set and checked?
Keep one SPF record per domain; add the DKIM public key under the vendor's selector; put DMARC at _dmarc, starting with p=none and a report address. Verify with DNS lookups and message headers, not just a vendor toggle.
Common mistakes: multiple SPF records (receivers may treat as permerror); too many SPF includes exceeding the 10-DNS-lookup limit; wrong DKIM selector/public key; duplicate DMARC records; a non-existent rua mailbox; configuring only the main domain and forgetting www, mail or marketing subdomains. Use the values from your mailbox/form vendor, wait for DNS TTL, then send a test and check spf=pass, dkim=pass and dmarc=pass in the headers.
| Record | Location/example | Check | Common error |
|---|---|---|---|
| SPF | Main domain TXT: v=spf1 include:... -all | Query TXT; header spf=pass | Multiple SPF/over 10 lookups |
| DKIM | selector._domainkey TXT public key | Header dkim=pass; selector matches | Wrong selector/domain |
| DMARC | _dmarc TXT: v=DMARC1; p=none; rua=... | Query _dmarc; reports arrive | Two records/invalid mailbox |
| Subdomains | Separate SPF/DKIM/DMARC for marketing/form subdomains | Test each domain | Only main domain configured |
| PTR | Sending IP reverse DNS to hostname | PTR/A match | Poor shared-IP reputation |
SPF syntax/lookup limits follow RFC 7208; Google's domain/PTR/TLS requirements are in its sender guidelines; record values follow the vendor docs.
How should DMARC move from none to reject?
Start at p=none to collect reports and find legitimate senders; then try quarantine at a small percentage; finally reject. Ramp with pct; do not reject everything at once and block inquiry/quote mail.
DMARC p=none is observation only; it does not tell receivers to block. Use it to see which IPs/services send for your domain. Once legitimate sources are covered by SPF/DKIM, move to quarantine with pct=10/25/50/100, then to reject. Subdomains can have their own policy via sp; alignment defaults to relaxed (organisational domain), while strict requires an exact match—do not switch to strict without understanding the impact. Use a dedicated mailbox for rua; external report destinations need an authorisation record.
| Stage | Policy | Purpose | Risk/note |
|---|---|---|---|
| Observe | p=none; rua=... | Collect reports; find legitimate/illegitimate senders | No blocking; reports need an owner |
| Small quarantine | p=quarantine; pct=10/25 | Check legitimate mail is not harmed | Notify sales/support first |
| Full quarantine | p=quarantine; pct=100 | Failures go to spam/quarantine | Monitor bounces/inquiries |
| Reject | p=reject; pct=100 | Reject unauthenticated/misaligned mail | Ensure all legitimate sources are covered |
| Subdomain | sp=quarantine/reject | Strict main domain, subdomains as needed | Subdomains still need SPF/DKIM |
The phased rollout follows Microsoft 365 DMARC guidance; p=none is for testing/tuning; confirm the policy against your senders and receiver behaviour.
How should form From/Reply-To be set?
Use your own domain in From (e.g. website@company.com) and put the visitor's address in Reply-To. Do not spoof the visitor in From, and do not let the form vendor send from its own domain without authentication. Auto-replies follow the same rule.
The most common delivery error is setting the form notification's From to the visitor's email. That makes your server impersonate the visitor's domain, likely failing SPF/DMARC and looking forged. Correct: From uses your domain (aligned with SPF/DKIM), Reply-To uses the visitor's address, and the body carries name/company/need. With a third-party form/SMTP service, ensure its sending domain is in your SPF or it signs DKIM with your domain; do not let it "send on your behalf" without authentication. Auto-replies also use the authenticated domain to avoid conflicting with human replies.
| Field | Recommendation | Why | Common error |
|---|---|---|---|
| From | website@yourdomain.com | Aligns with SPF/DKIM; builds domain reputation | Visitor/free-mail address |
| Reply-To | Visitor's email | Sales can reply directly | Reply-To also set to yourself |
| Envelope From | Vendor return path/your subdomain | Bounce tracking/SPF alignment | Forged/empty |
| Subject | Product/company/source, no fake reply | Recognisable; less spammy | "Re: inquiry" fabricated |
| Auto-reply | Authenticated domain + clear content + loop protection | Visitor knows it arrived | Duplicate/looping replies |
The field guidance is editorial; Gmail's From/Reply-To/bounce/authentication requirements are in its sender guidelines; form/vendor configuration follows their docs.
What counts as deliverability acceptance testing?
Send one round each to Gmail, Outlook, QQ/163, corporate mailboxes and an overseas mailbox; check inbox/spam/bounce, SPF/DKIM/DMARC results and the reply path; keep headers, screenshots and timestamps. Do not test one mailbox only.
Cover real scenarios: website form notification, auto-reply, sales reply, attachments/quotes, different languages/domains. For each recipient, check four things: received or not, inbox vs spam, header authentication (spf/dkim/dmarc), bounce code. In Gmail, "Show original" exposes Authentication-Results; corporate mailboxes expose headers/logs; third-party services expose send logs. Use the real domain and realistic content, not "test test"; control frequency to avoid rate limiting.
| Recipient | Check | Pass standard | Evidence |
|---|---|---|---|
| Gmail | Inbox/spam; original headers | spf/dkim/dmarc pass; inbox | Header screenshot |
| Outlook/Exchange | Inbox/spam; bounce | Authentication pass; no 5.7.x bounce | Headers/logs |
| QQ/163 | Inbox/spam | Received; links work | Screenshot |
| Corporate mailbox | Receive/forward/reply | Notification/reply chain works | Logs/screenshot |
| Overseas mailbox | Receive/delay/attachment | Received; attachment intact | Screenshot/time |
The test matrix is editorial; Gmail authentication/spam-rate requirements are in its sender guidelines; recipient rules follow each platform.
How should common failures be diagnosed?
Start with the bounce code and message headers, then check DNS (multiple SPF/lookup limit, DKIM selector, DMARC record), From alignment, third-party senders and IP reputation. Do not set DMARC to reject first.
Sequence: 1) any bounce/delay, and what code; 2) Authentication-Results status for spf/dkim/dmarc; 3) one SPF record, DKIM selector matches, valid _dmarc; 4) From domain aligns with SPF/DKIM; 5) form/mail vendor covered by SPF or DKIM; 6) shared IP on a blocklist; 7) recipient spam rules/full mailbox. After changes, wait for TTL and retest; keep before/after headers.
| Symptom | Likely cause | Check | Action |
|---|---|---|---|
| spf=fail | IP not in SPF/multiple SPF/over limit | TXT/headers | Merge/add include |
| dkim=fail | Selector/public key/signing domain wrong | DNS/header d= | Reconfigure per vendor |
| dmarc=fail but SPF/DKIM pass | Domain misalignment | From vs MAIL FROM/d= | Fix From/MAIL FROM/signing domain |
| Spam folder | Reputation/content/volume/SPF gap | Postmaster/logs | Authenticate/reduce/change content |
| 5.7.x bounce | Authentication/policy/blocklist | Bounce code | Fix/appeal per code |
| Fails after forwarding | SPF breaks/body changes | ARC/forward path | DKIM/ARC/adjust forwarding |
The diagnosis table is editorial; DMARC alignment/report interpretation follows Microsoft 365 documentation; bounce codes follow the mailbox provider.
Launch acceptance checklist
Accept eight items: sending-domain list, SPF, DKIM, DMARC, From/Reply-To, third-party services, test matrix, monitoring/response. Each needs an owner and evidence—not just "the form submits".
The checklist can be shared by marketing, sales, IT/operations, website vendors and mailbox providers. The pass standard is not "a DNS record exists" but authentication passes, domains align, major recipients deliver to inbox, the reply path works, bounces are traceable and reports have an owner.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Domain list | Main/subdomain/form/marketing domains listed | Domain table | Complete list/records |
| SPF | One record, all senders covered, under lookup limit | DNS/headers | Merge/adjust |
| DKIM | Selector/key/signing domain correct | Header dkim=pass | Reconfigure/rotate |
| DMARC | Valid record, policy at the right stage, reports reachable | DNS/reports | Fix/downgrade |
| From/Reply-To | From your domain; Reply-To visitor | Test email | Fix form/template |
| Third-party services | Form/mail vendors authenticated/aligned | Vendor docs/logs | Add SPF/enable DKIM |
| Test matrix | Gmail/Outlook/QQ/163/corporate/overseas pass | Headers/screenshots | Fix each |
| Monitoring/response | Bounce/report/alert owner | Dashboard/rota | Add process/training |
The acceptance checklist is editorial; SPF/DKIM/DMARC, DNS, mailbox and form configuration depend on standards, vendor docs and company policy.
Who should read this, who should not, and what decision does it support?
It fits Changzhou manufacturers with website inquiry forms, notification emails or corporate-domain mail. It does not fit projects without a sending domain, or teams expecting a new form plugin or one SPF record to fix everything.
Who should read: marketing, export/sales, IT/operations, website vendors and mailbox providers; teams launching/redesigning a website, changing form/mail vendors, seeing inquiry mail in spam or bounces, or facing domain spoofing; anyone deciding "how to set SPF/DKIM/DMARC, From/Reply-To, how to ramp DMARC, how to test". Who should not: projects without an owned domain/sending system; teams only changing form styling and ignoring DNS/headers; teams expecting one checklist to replace mailbox/IT implementation. Decisions supported: sending-domain inventory, SPF/DKIM/DMARC configuration, form sending design, DMARC rollout, test matrix, troubleshooting and launch acceptance.
Lingyi Information is a website and enterprise AI project services company, not a mailbox provider, DNS host or security auditor. This article does not replace mail-system configuration, DNS changes or a security assessment. Changzhou projects are confirmed case by case for remote or on-site work; Lingyi is one candidate, not a local office/team, and does not promise deliverability, inquiry volume or conversion.
FAQ
Why do website inquiry emails go to spam?
Common causes: no SPF/DKIM/DMARC, From not aligned, the form spoofs the visitor's address, a third-party form service is missing from SPF, a shared IP has poor reputation, or content/frequency triggers spam rules. Check the bounce code and headers first, then DNS and form sending.
Is SPF alone enough?
No. SPF only authorises sending servers; it does not verify content or set failure handling, and forwarding/third-party senders can break it. Use SPF + DKIM + DMARC together: DKIM signs, DMARC enforces alignment/policy and provides reports.
Can we set DMARC to p=reject right away?
Not recommended. First include every legitimate sender (website, form, mail service, marketing, OA/ERP) in SPF/DKIM, observe with p=none, then quarantine at a small percentage, then reject. Otherwise you may block inquiry, quote or auto-reply mail.
Can the form use the visitor's email in From?
Not recommended. Use your own domain in From (e.g. website@yourdomain.com) and the visitor in Reply-To; otherwise you impersonate the visitor's domain and may fail SPF/DMARC or look forged. Auto-replies should use the authenticated domain too.
What changes when we switch website/mail vendors?
List the new vendor's sending domain/IP/selector, update SPF (include), DKIM (selector/key) and DMARC (reports/policy), then rerun the test matrix. Remove old records only after confirming no business uses them.
How do we know the domain is spoofed or the config works?
Review DMARC aggregate reports (rua) for source IPs/pass rates and message headers for spf/dkim/dmarc. Gmail Postmaster Tools shows domain reputation/spam rate. After DNS changes, wait for TTL, retest across recipients and keep the headers.
Bottom line
For a Changzhou manufacturer's website inquiry email, do not accept only "form submitted": authenticate the sending domain with SPF+DKIM+DMARC, use your own domain in From and the visitor in Reply-To, authenticate/align third-party forms, ramp DMARC from none to quarantine/reject, and test Gmail/Outlook/QQ/163/corporate/overseas mailboxes with saved headers.
Method and limits
This article is public standards, platform documentation and project method, not a configuration certification or security advice for any company, domain, mailbox, form or vendor. It uses no unpublished client mail, domains or logs. The configuration table, test matrix and acceptance checklist are editorial; SPF/DKIM/DMARC, DNS, mailbox, form and compliance requirements depend on standards, vendor docs, company policy and IT/security review.
Sources
Information is current to 31 October 2026; each official/primary page governs its own syntax, policy and behaviour.
- RFC 7208, Sender Policy Framework (SPF) (April 2014): rfc-editor.org. SPF record syntax, authorisation, DNS lookup limit and results.
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures (September 2011): rfc-editor.org. DKIM signing, selectors, DNS public keys and verification.
- RFC 7489, DMARC (March 2015): rfc-editor.org. DMARC alignment, p/sp policy, pct and rua/ruf reporting.
- Google Workspace, Email sender guidelines (current 2026): support.google.com. Gmail requirements for SPF/DKIM/DMARC, alignment, PTR, TLS, spam rate and Postmaster Tools.
- Microsoft Learn, Set up DMARC to validate email in Microsoft 365 (updated 3 July 2026): learn.microsoft.com. DMARC syntax, none→quarantine→reject rollout, pct, reports and alignment troubleshooting.