MX, SPF, DKIM and DMARC: What They Are and Why Emails Do Not Arrive

What DNS is and why email needs several different records

DNS is the Domain Name System. It stores information that software uses to find domain services and retrieve policies published by the owner. A company domain can be used simultaneously for both a website and email. A functioning website by itself says nothing about the accuracy of email settings.

The word "record" refers to an individual entry in this information. Records have different types and purposes. MX defines where incoming mail is routed. SPF and DMARC are published as text entries. For DKIM, data is placed in DNS to verify signatures. That is why a request to "check DNS" requires clarification: which specific email and which function are being investigated.

It is helpful to separate the two directions. Incoming emails arrive at the company from partners. Outgoing emails leave the company to staff at other organizations and clients. An issue with incoming mail does not indicate a problem with outgoing email signatures. A valid signature, in turn, does not fix an incorrect address that a counterparty is trying to reach.

Mailbox access itself is a separate matter. IMAP handles reading and synchronizing email in the client, while SMTP is used for sending. If an app cannot connect to the email service, having correct domain records will not restore its access.

What an MX record is and what it does

An MX record specifies which mail servers accept messages for a domain. When a partner writes to a corporate address, their email system uses this information to locate the receiving side. When multiple MX records exist, they have priorities that determine server selection.

Imagine a company address in a directory. It helps deliver mail to the right building. However, having an address does not prove that the required office exists inside. Similarly, an MX record does not create an employee mailbox, alias, or shared department address. The receiving mail system must know which addresses it hosts.

An incorrect server in an MX record can explain why incoming emails fail to arrive or get routed to another email system. But the absence of a single message in the Inbox folder does not prove an MX error. The message could have landed in another folder, been rejected by the receiving server, or been sent with a typo in the address.

For troubleshooting, it helps to know the recipient's full address and obtain a non-delivery report (bounce message) if available. The phrase "no one is emailing us" is too broad. Clarify whether all company addresses, a specific employee, or a shared inbox are affected. These are distinct symptoms that help a specialist determine the scope of the problem.

An MX record does not authorize a server to send email on behalf of a company. Incoming and outgoing email can be handled by different systems. Therefore, the conclusion that "the MX is correct, so the sender is verified" is false. Other mechanisms exist for outgoing messages.

SPF is a check for authorized sending sources

SPF is a mechanism that allows the receiving side to verify whether the sending server's IP address is authorized by the policies of the domain being checked. The domain owner publishes these rules in DNS. The recipient compares them against the source of the specific message.

An important detail: SPF typically checks the domain of the technical return-path address used during message transmission. This is not necessarily the address a person sees in the From line. SMTP has envelope metadata, while the email has its own headers. Mixing up these levels makes it easy to misinterpret verification results.

A company may have several sources of outgoing messages. Employees reply from an email service, the website sends inquiries, and the CRM sends notifications about documents. For each source, it is vital to understand where the email actually originates. A successful send by an employee does not confirm that the website will achieve the same result.

A common mistake occurs when authorizations do not match active senders. In that case, a legitimate company system may fail SPF. The opposite extreme is also undesirable: overly broad authorization makes the check far less useful. Rules must reflect real sources, and their purpose should be clear to the administrator in charge.

SPF does not sign email content and does not prove that a user read the message. It answers a narrow technical question about the sending source. Therefore, its result should be evaluated alongside other data, rather than turned into a sweeping verdict of "email works properly."

DKIM is an email signature, not an IP allowlist

DKIM is a digital signature mechanism for email messages. The sending system attaches a signature, and the recipient verifies it against the public key published for the specified domain. The signature covers specific headers and email body content according to DKIM rules.

A valid signature helps confirm that the signed parts of the message were not altered after signing. It also demonstrates the link between the signature and the domain specified in it. This is a technical confirmation. It does not assess the honesty of the text, the authenticity of an invoice, or the authority of the person who wrote the email.

The signature specifies a selector. This is an identifier the recipient uses to locate the matching public key in DNS. If the signature points to a key that is unavailable or does not match, verification cannot succeed. Such a discrepancy must be examined at the level of the signing system and the published records.

Another possible cause of an error is that signed parts were altered after signing. That is why a simple notification like "DKIM failed" is not enough. It is essential to inspect the actual email with its technical headers and understand which systems it passed through. An employee's summary of the text does not preserve this data.

SPF and DKIM complement each other, but verify different things. SPF checks source authorization. DKIM verifies the signature. A passing SPF check does not imply a valid DKIM signature, and a passing DKIM check does not mean SPF passed as well. A specialist's assessment must include separate results for each.

What DMARC is and why the domain in the "From" line matters

DMARC is a mechanism for verifying the visible sender domain based on SPF and DKIM. It helps the receiving system evaluate whether technical verifications align with the domain a person sees in the "From" field. This alignment is called domain alignment.

For DMARC to pass, a passing SPF with proper alignment or a passing DKIM with proper alignment is sufficient. The word "pass" in the SPF line alone does not mean DMARC passed. The check might have succeeded for a different domain that does not align with the visible sender domain.

A DMARC policy tells recipients how the domain owner wants them to handle messages that fail verification. Reports are also provided. They help you see how the domain is being used and the results of verification checks. Receiving a report by itself does not fix an identified issue and does not explain the business purpose of each sender.

The primary purpose of this mechanism is to protect against sender domain spoofing. However, DMARC does not verify whether the email content is truthful, nor does it block every method of deception. An attacker can use a lookalike name, a different domain, or someone else's compromised account. Employees still need clear rules for verifying unusual requests.

It is useful for a company to ask: does the recipient's perception of the sender match the technically verified domain? You should ask this separately for employee correspondence, the website, and business software. Different sources can have different technical addresses and signatures, even if they outwardly use the name of the same organization.

Why an email can still end up in spam

Passing SPF, DKIM, and DMARC checks confirms specific technical properties of a message. They do not obligate the receiving service to place it in the inbox. The decision can be influenced by sender reputation, content, attachments, recipient complaints, and internal rules of the receiving system.

It is helpful to distinguish between three outcomes. An email can be rejected with an error message. It can be accepted but placed in junk mail. Finally, it can sit in the mailbox while the user does not see it because of folder routing or filtering rules. Each scenario requires its own verification.

A "sent" status in an app often simply means the message was accepted by the nearest sending system. It does not confirm that the recipient read it, and it does not always indicate the final folder. Ask for the exact status description and any available notification about the outcome, rather than jumping to conclusions based on a single green checkmark.

Fictional example. At a hypothetical company in Almaty, employee emails reach partners, while website notifications land in spam. This is not a contradiction: the sending sources are different. Troubleshooting requires separate samples of both emails. Checking only an employee mailbox and applying that result to the website is not enough.

Another fictional case: a partner reports not receiving an email, even though another recipient sees it. This is a reason to compare specific addresses and responses from the receiving systems. It is too early to conclude that the entire corporate email system is broken based on one recipient. It is just as premature to promise a fix by changing a single record.

What to prepare for a thorough investigation

Collect details about the problematic message: sender address, recipient address, subject line, time sent, and the app name. Save the non-delivery notice in full. If the message went to spam, ask the recipient to save it with full technical headers. Agree on how confidential correspondence will be protected before sharing it.

List all known sending sources: employees, website, CRM, 1C, printers, and scanners. Note who is responsible for each system and where its documentation is kept. Do not send passwords in unencrypted messages. To discuss the issue, it is usually more important to understand the systems involved and the nature of the issue than to gather a random set of credentials.

Clarify separately who manages the domain and corporate email. These roles may belong to different people or contractors. Management needs a clear answer on who controls the settings and who handles support requests. When choosing between provider hosting and your own infrastructure, use our breakdown of in-house mail servers vs. the cloud.

For businesses in Kazakhstan, review questions about email handling and personal data processing with legal counsel, taking your industry and contracts into account. Technical correctness of records does not replace legal evaluation. Verify availability questions and terms of service directly with the specific provider.

Frequently asked questions

Are MX and SPF the same setting?

They serve different purposes. MX specifies the domain's receiving servers. SPF helps verify an authorized source of an outgoing message. Working incoming mail does not prove that outgoing sending is configured correctly, so results are evaluated separately for each specific situation.

If DKIM passes, is the email definitely authentic?

A successful check confirms the signature and the integrity of the signed parts. It does not prove the truthfulness of the text or the author's right to request payment. Verify unusual requests according to company policies, even if the message passes all technical checks.

Why does DMARC fail when SPF passes?

DMARC requires alignment with the visible sender domain. SPF may successfully validate a different technical domain. You need details about the specific message and DKIM results to understand the DMARC outcome and the reason for the discrepancy.

Do correct records guarantee delivery to the inbox?

No. The recipient applies their own rules and considers other message attributes. Technical checks are only part of the evaluation. If an email ends up in spam, save it and analyze the results alongside sending source data.

Will DNS help if an email client cannot connect?

The issue might lie in service access, authentication, or provider restrictions. MX, SPF, DKIM, and DMARC do not grant an app permission to log into an inbox. Describe the connection error separately from delivery errors to avoid mixing up two different issues.