Keep Your Email Out of the Spam Folder with DMARC, SPF, and DKIM

When a proposal you send to a customer lands in their spam folder, the sale is left half-done. At the same time, attackers spoofing email from your brand can damage your business reputation. SPF, DKIM, and DMARC are email-authentication standards that solve both problems. Configured correctly, delivery rates rise and phishing attacks become harder. This guide offers a practical roadmap for SMEs.

Why Does Email Authentication Matter?

Today's email servers (Gmail, Outlook, Yahoo) want to verify that an incoming message really comes from the domain it claims to. Three standards form the foundation of this verification: SPF (sender server authorization), DKIM (digital signature), DMARC (policy notification). Common problems in businesses where these records are missing or wrong:

• Emails sent to customers landing in spam
• High delivery-failure rate (bounce)
• Attackers sending spoofed email from the company domain
• Email traffic suddenly cut by Google/Microsoft updates
• Low open rate on marketing emails
• Customers saying "I got this from you" while falling for spoofed mail
• Corporate email reputation weakening

Most of these problems are solved by adding three correct records to DNS.

What Do the 3 Standards Do in Practice?

SPF (Sender Policy Framework)

SPF is a DNS record that lists which servers are authorized to send email from your domain. For example, if only Microsoft 365 servers are authorized for the yamanlarbilisim.com.tr domain, the SPF record announces it. The receiving server treats email from a server not on the list as suspicious.

Example SPF record:

v=spf1 include:spf.protection.outlook.com -all

The -all part means "reject every server not on the list."

DKIM (DomainKeys Identified Mail)

DKIM attaches a cryptographic signature to outgoing email. The receiving server verifies this signature against the domain's public key in DNS. If the signature is valid, the email's content has not been altered in transit and is proven to have come from your server.

A DKIM DNS record typically looks like:

selector1._domainkey.yamanlarbilisim.com.tr  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

DMARC (Domain-based Message Authentication)

DMARC tells the receiving server what to do when SPF and DKIM verifications fail: mark, quarantine, or reject. It also sends reports of failed emails to the address you specify.

Example DMARC record:

_dmarc.yamanlarbilisim.com.tr  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yamanlarbilisim.com.tr"

The policy is rolled out in stages: start with p=none to only collect reports, then p=quarantine, finally p=reject.

Step-by-Step Setup

1. Check existing records. Use online tools (MXToolbox, Google Admin Toolbox) to view the status of your SPF, DKIM, and DMARC records. Most SMEs have none or partial records.

2. List sending servers. If email is sent from Microsoft 365, Google Workspace, mail hosts, or services like Sendgrid, they all must be included in the SPF record. A missing source creates verification failures for legitimate email.

3. Add the SPF record. Add a TXT-type record at your DNS administrator (domain provider panel or IT team). At first, ~all (soft fail) is recommended; after a few weeks of testing, switch to -all (hard fail).

4. Activate DKIM at your email provider. In Microsoft 365 and Google Workspace admin panels, a DKIM record is generated with one click. Add it to DNS following the vendor's instructions.

5. Start DMARC with p=none. At this stage the policy only collects reports; no email is blocked. Reports sent to the rua address map legitimate and spoofed traffic.

6. Review reports for 2-4 weeks. Identify legitimate emails coming from unexpected sources (e.g., accounting software, CRM) and add them to SPF.

7. Tighten DMARC in stages. When reports look clean, switch to p=quarantine (failures go to spam), and another month later p=reject (failures are rejected).

Quick Reference Table

Standard	What it does	Setup difficulty
SPF	Authorized sender server list	Low — single TXT record
DKIM	Digital signature on outgoing email	Medium — key generated at the provider
DMARC	Policy + reporting	Low — single TXT record

When all three are deployed together, a mature authentication structure is achieved.

Common Mistakes

• SPF record requiring more than 10 DNS lookups (exceeds the standard limit)
• Creating more than one SPF record (only one should exist)
• Generating DKIM but not adding it to DNS
• Starting DMARC at p=reject directly — legitimate email can be blocked
• Never reviewing DMARC reports
• Third-party marketing services not added to the SPF record
• DKIM keys not rotated on domain changes

Real-World Examples

Example 1: Delivery Issue at an Accounting Firm

At an accounting firm, proposals sent to customers were landing in Gmail's spam folder. Analysis found the SPF record was incomplete and DKIM was not active. DKIM was activated in Microsoft 365 and SPF updated. The rate of falling to spam dropped noticeably.

Example 2: Spoofed Email at a Manufacturing Site

A manufacturing site was told customers were getting fake bank-information emails appearing to come from the company domain. With a DMARC p=reject policy, emails from spoofed servers were rejected by recipient servers. Subsequent attempts bounced back directly.

Example 3: DMARC Reporting at a Consulting Firm

By reviewing DMARC reports, a consulting firm noticed that its CRM integration was sending legitimate email but was not in SPF. SPF was updated; automated emails from the CRM now pass verification successfully.

How Does Yamanlar Bilişim Support This Process?

Yamanlar Bilişim reviews the current email-authentication state and rolls out SPF, DKIM, and DMARC records on a phased plan. Throughout reporting and policy tightening, legitimate email traffic is monitored, and no disruption is allowed.

Main areas where Yamanlar Bilişim can support:

• Analysis of existing DNS records and gap identification
• SPF record creation and optimization
• DKIM activation on Microsoft 365 or Google Workspace
• Phased DMARC policy rollout
• Regular DMARC report analysis and recommendations
• Integrating third-party email services into the records
• Delivery-rate monitoring and improvement
• General email-security hardening

FAQ