Business email authentication with SPF, DKIM and DMARC
· PoolByte
A message sent from a corporate email address must actually leave the system authorized by the company. However, the appearance of the brand's name in the address line does not alone prove this. SPF, DKIM and DMARC are verification methods that complement each other. Proper setup makes it easier to investigate delivery issues and limit unauthorized use of the domain; does not guarantee that all messages will reach your inbox.
The examples in this guide are for educational purposes only. Replace example.com and the sample sender information with your own domain name and the records provided by your provider. If record types are unfamiliar to you, first review the DNS records guide.
First list all senders
A company may not only send messages from its employees' email app. The website's contact form, order notifications, accounting software, support desk, and marketing system may also use the same domain name. First, write down who manages these systems, the apparent shipper address, and the actual shipping provider.
For example, if employees use an email service, the website uses a separate SMTP account, and campaigns use a third platform, all three flows should be examined. Turning on a strict DMARC policy by only testing employee sending may impact order messages. If the old provider is no longer used, question the reason for keeping it on the register; Unnecessary authorizations should be cleared.
SPF: Permission granted to the sending source
SPF defines via DNS which systems can send messages on behalf of the domain name used in SMTP sending. The From address of the email that appears to the recipient does not have to be the same as the address that SPF evaluates. This distinction is important for understanding DMARC alignment.
Do not publish multiple separate SPF records on the same name. When changing a provider, old and new authorizations are combined into a single record, if necessary. The SPF standard limits the total number of evaluations of terms include, a, mx, ptr, exists, and redirect that require a DNS lookup to ten, including the child include chains. If this limit is exceeded, permerror may occur; The limit is not the number of all physical DNS queries. Don't check just by looking at the text.
For a hypothetical sending server, the record might look like this:
example.com TXT "v=spf1 ip4:192.0.2.10 -all"This is reserved for IP document examples; should not be copied to the live configuration. If your provider requires include, use its current value. The SPF record does not replace the MX record that forwards incoming mail.
DKIM: The system that signs the message
DKIM signs the sent message with a private key; the recipient searches for the corresponding public key in DNS. The selector, record name and key value provided by the provider must be used together. The record name is usually in the format secici._domainkey.example.com. Some services require CNAME pointing to their infrastructure instead of TXT; Follow the panel's instruction.
The private key is not put into DNS or the blog post. Multiple senders may use different selectors. Publishing the new selector on key exchange and validating it from submission is a more controlled approach than immediately deleting the old selector. Once the migration is complete, create a separate task to remove old authorizations.
DMARC: Alignment with visible sender
DMARC evaluates whether the apparent sender domain is properly aligned with the SPF or DKIM-verified domain. It is not necessary for both methods to be successful at the same time; aligned SPF or aligned DKIM success may be sufficient. Just seeing “pass” for SPF on a test screen does not mean that DMARC is passed.
In order to make observations with reports during the first installation, a record like the following can be considered:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"The report address should actually work. If you're using another organization's reporting domain, check the service's documentation for any additional authorization required. p=none is an observation policy; DMARC does not want failed messages to be rejected due to this policy. Once legitimate senders are verified, quarantine or reject is evaluated. Receiving systems also implement their own decisions.
How do you verify the change?
- Obtain a dated copy of current DNS records.
- Prepare a different test message for each shipping system.
- Send the message to different recipient services and review the full headers.
- Save the SPF result, the domain name in the DKIM signature, and the DMARC result separately.
- Measure again after the change, taking into account DNS cache times.
- Examine unknown sources in reports; Don't automatically provision every failed resource.
You don't need to send real customer data or invoices for testing. Writing the name of the flow in the subject line, for example “contact form validation test,” will prevent you from confusing the results. Because report files may contain operational information, limit their access and set a retention period.
Frequently asked questions
If there are three records, why does it end up in the spam folder?
Content, buyer complaints, shipping habits and sender reputation are also evaluated. While authentication is an important foundation, it is not a substitute for authorized communication and healthy list management.
Should records be re-established when moving a domain name?
If the authoritative DNS service is changing, it is necessary to verify the existing MX, SPF, DKIM and DMARC records in the new region. Just changing the web server IP does not require changing all email records.
What information should I give to the support team during installation?
Domain name, shipping services used, time of failed test, and titles with personal data cleared are a sufficient start. Do not share passwords or private keys. You can review domain name options and contact us from contact page to evaluate the configuration.