Business Email and Domain Sending Setup: SPF, DKIM, and DMARC in Plain English, and Why Forms and Newsletters Land in Spam

“A customer says they filled in the contact form on our website, but we never got the notification.” “We sent out the newsletter, and several long-time customers said they only found it in their spam folder.” Situations like these are very common in small and medium businesses, and they usually get blamed on “the content looks too much like an ad.” In practice, the more common cause is that the business email and domain sending setup was never completed: the receiving side cannot confirm that the message really was authorized by you, so it treats it as suspicious.

Sender authentication for a domain relies on three settings: SPF, DKIM, and DMARC. The names are technical, but the idea behind them is not hard to follow. It is like a company stamping official documents with its seal and sending them in company envelopes, so the recipient can trust that nobody is impersonating it.

What follows explains in plain terms what each of the three proves, why forms and newsletters are especially prone to trouble, how sending services and mailbox services divide the work, and how to verify the setup yourself, ending with a self-check list you can use directly.

Why “it sent” does not mean “it arrived”

Many people assume that if they press send and no error appears, the other side received the message. In reality, after it leaves, the message passes through a series of judgments on the receiving end: Does this message really come from the domain it claims? Has this sending source been reported before? Does the content look like a scam? If it loses points at any of these checks, it may land in spam or even be blocked outright without the sender ever knowing.

The problem is that the “From” field of an email can say anything. Anyone can write a message and put your company’s domain as the sender. That is exactly the trick phishing and scam emails rely on most. To fight impersonation, the major mailbox providers check: has the owner of this domain publicly declared which systems may send email on its behalf?

That declaration lives in the domain’s DNS settings. If DNS is unfamiliar territory, start with Domain and DNS Basics to understand how domains, DNS records, and hosting services relate; this article focuses only on the records that concern sending email.

What SPF, DKIM, and DMARC each prove

The three are often mentioned together, but they solve different problems, and missing any one of them can make authentication fail.

SPF: who is allowed to send for you

SPF is an authorization list, written in a text record in the domain’s DNS, that names which mail servers may send email using this domain. When a message arrives, the receiver checks whether the server that actually sent it is on the list.

A plain analogy: the company posts a notice at the front desk saying “only these few couriers may send and receive shipments on our behalf.” Anything delivered by a courier not on the list makes the front desk suspicious.

The usual SPF problem is an incomplete list. The company’s mailbox service is included, but the newsletter platform, the website host, and the customer-service system are not, so every message those systems send is treated as impersonation. Another problem is that a domain may have only one SPF record. Some people add a new record every time they sign up for a new service, which actually invalidates the whole authorization. The correct approach is to merge all the sources into a single record.

DKIM: was the message altered, and did you really sign it

DKIM is a digital signature. The sending system signs each message with a private key, and the matching public key is published in DNS. The receiver uses the public key to check whether the signature matches. If it passes, the message really was issued by an authorized system and its content was not changed in transit.

A plain analogy: the document carries the company seal, and the recipient compares it with a public specimen of the seal. Only a match counts.

DKIM requires the sending service to “turn on signing” on its side, and then you add the public-key record it provides to DNS. Doing only half — signing turned on at the service but no DNS record, or the DNS record added but signing never turned on — means authentication will not pass.

DMARC: what to do when authentication fails

SPF and DKIM are two ways of proving identity; DMARC is the policy. It tells the receiver what to do with a message that claims to come from your domain but fails authentication: just observe, put it in quarantine, or reject it outright.

DMARC is useful in two more ways. First, it requires the authentication result to line up with the sender domain shown in the message, closing the loophole of “pass SPF with some other domain while writing your domain in the From field.” Second, it can ask receivers to send back aggregate reports regularly, so you can see which sources are using your domain to send mail, including systems you had forgotten about, and impersonators.

Why website forms and newsletters are especially prone to trouble

Staff emailing each other through the mailbox service usually has no problem, because large mailbox providers have generally handled authentication in their default setup. What tends to break is mail that is not sent from the mailbox service.

Website form notifications: after a form is submitted, the web host or the back-end code sends you a notification email. Many websites do this by sending directly from the host and filling in the company mailbox as the sender. But the host’s server is not on the SPF list and has no DKIM signature, so the result is a message that “claims to be you but cannot prove it,” and your own mailbox blocks it or drops it in spam.

Another common situation is a form that uses “the email the customer typed in” as the sender. That amounts to sending mail with someone else’s domain, and authentication is bound to fail. The correct approach is to use a fixed, dedicated address on your own domain as the sender and put the customer’s address in the reply-to field. A form that gets flooded with spam also drags down your sending reputation; for protection methods, see Protecting Website Forms from Spam.

Newsletters and marketing email: newsletter platforms usually offer domain authentication, but you have to add the corresponding records in DNS yourself. Skip that step and the platform sends on your behalf with its own domain; recipients may see a “sent via some platform” notice, trust drops, and the chance of landing in spam goes up. Beyond the technical setup, list management and sending frequency matter just as much, which Email Marketing and Word of Mouth covers in full.

System notifications: order confirmations, password resets, shipping notices. When customers do not receive these, they call customer service directly, or even suspect a scam. These are the messages you can least afford to have treated as spam, so their authentication should be fixed first.

How sending services and mailbox services divide the work

Many companies treat “business email” and “sending email” as the same thing, but technically they are usually different services, each covering one part.

Service type	What it handles	Typical use
Mailbox service	Receiving and storing mail, staff’s everyday email	Business correspondence, internal communication
Transactional sending service	Single automated messages sent by systems	Form notifications, order confirmations, password resets
Marketing sending platform	Bulk sending, list and unsubscribe management	Newsletters, event announcements

The benefit of splitting the work is that one does not drag down another. Marketing mail naturally draws more complaints, and if it shares a sending source with staff business mail, one bad send can affect business correspondence too. A common practice is to send marketing mail from a subdomain — for example, one subdomain dedicated to newsletters — so it builds reputation separately from business mail on the main domain.

Splitting the work also means each service has to complete authentication on its own: the mailbox service, the transactional sending service, and the marketing platform each get added to the SPF authorization and each turn on DKIM signing, with a single DMARC policy governing them all. Leave any one out and mail sent through that channel will have problems.

Rollout order: start with an inventory, not with DNS edits

A mistake in DNS can affect incoming mail for the whole company, so take stock before touching anything.

1. List every system that sends email using the company domain: the mailbox service, the website host, the newsletter platform, the customer-service system, the e-commerce back end, the accounting or invoicing system. If you are not sure, ask each department, “Do you have any system that automatically emails customers?”
2. Confirm how each system sends: does it send by itself, or through an external sending service? What SPF and DKIM settings does each need?
3. Merge SPF: gather all legitimate sources into a single record.
4. Turn on DKIM one by one: each service generates its own key and adds it to DNS.
5. Start DMARC in monitor mode: collect reports only, take no action, and observe for a while.
6. Read the reports and close the gaps: find legitimate sources that are not yet authenticated and fix them, and identify impersonating sources at the same time.
7. Tighten the policy step by step: once every legitimate source passes, move from monitor to quarantine and finally to reject.

Keep a record throughout: which service each DNS record was added for, who added it, and when. Later, when you switch services or hand over the work, nobody will be stuck asking “what is this record and can we delete it?” with no answer. Who controls the domain and DNS is also part of company security; for the principles, see Website Security Basics for Business.

How to verify after setup: a self-check list

Being set up is not the same as working; you have to verify it. Use this list to check item by item:

• Submit a test entry through the website form and confirm the notification lands in the inbox, not in spam.
• Open the message you received and view its original headers (most mailbox services have a “show original” option) to confirm that SPF, DKIM, and DMARC all show as passed.
• Test receiving with several common mailbox services, not just your own.
• Before sending a newsletter, send a test to internal staff and confirm the sender shows your own domain, with no “sent via another platform” notice.
• Confirm the domain has only one SPF record.
• Confirm each sending service’s dashboard shows domain authentication as complete.
• The DMARC reports go to a designated mailbox, and someone is responsible for reading them regularly.
• System notifications (orders, password resets) have each been tested once.
• The sender address is never the email the customer typed in.

When verifying, the message headers are more reliable than “did it reach the inbox,” because inbox placement is influenced by other factors too. The authentication results in the headers are the direct evidence of whether the setup itself is right.

Long-term maintenance: do not let the setup quietly break

Sending setup is not something you do once and forget. In practice it commonly breaks for a few reasons:

A new system goes live and nobody tells the person who manages DNS. Marketing switches newsletter platforms, sales adopts a new quoting tool, and mail sent from it fails authentication from day one. Consider adding “does it send email?” to the checklist for adopting any new system.

Domain renewal or DNS hosting changes. When a domain expires or the DNS host changes hands, records can be lost. Set reminders for the domain’s expiry date, and make sure the notices go to more than one person’s mailbox.

Nobody reads the DMARC reports. If the reports arrive and nobody reads them, you lose the chance to spot impersonation and gaps. Schedule regular checks, or bring key sending flows under monitoring; the approach is covered in System Monitoring and Alerts Explained.

Bounces go unhandled. Repeatedly sending to addresses that no longer work drags down sending reputation. Newsletter platforms usually handle bounces automatically, but notifications sent by your own systems need separate attention.

Sender authentication is infrastructure that stays invisible until something goes wrong. A missed form notification may cost you one inquiry; a newsletter that keeps landing in spam costs you the value of the whole list.

Closing thoughts

Think of SPF, DKIM, and DMARC as three things: who may send on your behalf, whether the message is really signed by you, and what to do when authentication fails. Only with all three in place does the receiver have a reason to trust you. The setup itself is not complicated. The hard part is taking a clear inventory of which systems send mail, and keeping that list current as the company adopts new tools.

If your website form notifications often go missing, or you want to move form and order notifications onto a transactional sending service, talk to NETVANA about your current situation. We can help inventory your sending sources, adjust how your website and systems send email, and tidy up the authentication settings along the way. Software work is quoted after a consultation, based on the actual scope; the services we offer are listed in the software services overview.

Further reading: For the basics of DNS and domains, start with Domain and DNS Basics. If spam flooding your form is hurting your sending reputation, see Protecting Website Forms from Spam. For managing newsletter lists and content, read Email Marketing and Word of Mouth. For domain permissions and account management, see Website Security Basics for Business. And if you want someone to know when a key sending flow breaks, see System Monitoring and Alerts Explained.