Why Small Businesses Should Look Beyond the Login Screen

Cloud platforms such as Microsoft 365 Security and Google Workspace give small companies access to email, documents, calendars, collaboration tools, customer information, and business records from almost anywhere. That convenience also means a single poorly configured account can expose far more than an employee’s inbox.

Small business cloud security is not only about adding another security product. It starts with checking how accounts, permissions, applications, sharing settings, devices, and recovery options are configured. Many dangerous gaps are created during setup and then forgotten as the business grows.

The following issues are among the first areas worth reviewing.

1. Multi Factor Authentication Is Not Enabled

Passwords alone provide limited protection against stolen credentials. Multi factor authentication requires an additional verification method, making unauthorized access harder even when a password has been compromised.

Review every user account, especially administrators, finance staff, executives, and anyone with access to sensitive files.

2. Administrator Accounts Are Overused

Administrator accounts can change settings, create users, assign permissions, and access important information. Giving administrative privileges to too many people increases the impact of a compromised account.

Keep administrator access limited and use standard accounts for everyday work.

3. Former Employee Accounts Remain Active

An employee leaving the company should trigger an immediate account review. An active account that no longer has a legitimate owner can become an easy route into business systems.

Disable accounts promptly and review their licenses, file ownership, email forwarding, application access, and delegated permissions.

4. Shared Accounts Have No Clear Owner

Accounts such as sales@, support@, or billing@ can become difficult to manage when several people share one password. It may also be unclear who has access or when that access should end.

Use delegated access, groups, or role-based permissions where the platform supports them instead of relying on shared credentials.

5. External File Sharing Is Too Broad

Cloud storage makes it easy to share documents with customers, contractors, and suppliers. A broad sharing setting can also make sensitive information available to people who do not need it.

Review public links, external collaborators, shared folders, and anonymous access. Set sharing rules according to the sensitivity of the information.

6. Users Have More Permissions Than They Need

A user does not need access to every folder, application, or business record simply because the technology makes it possible.

Apply least-privilege access. Give employees the permissions required for their responsibilities and remove access that no longer serves a business purpose.

7. Old Applications Still Have Account Access

Employees often connect cloud accounts to applications for scheduling, file management, productivity, or other tasks. Some of those applications may remain connected long after they are no longer used.

Review connected applications and revoke access for tools that are outdated, unnecessary, or unfamiliar.

8. Security Defaults Were Never Reviewed

Cloud platforms frequently provide protective settings that can be enabled or adjusted during setup. Businesses sometimes accept the initial configuration and never return to review it.

A cloud configuration security review should examine authentication, account recovery, application permissions, sharing controls, administrator roles, logging, and other available safeguards.

9. Conditional Access Rules Are Missing or Too Basic

Businesses using Microsoft 365 can use Conditional Access to apply access requirements based on factors such as user identity, device status, application, location, and risk signals.

For example, administrators may require stronger verification for sensitive applications or restrict access from devices that do not meet company requirements.

10. Email Forwarding Rules Go Unnoticed

Unexpected forwarding rules can redirect business email to external addresses. This is particularly concerning for accounts handling invoices, customer information, payment instructions, or confidential conversations.

Review mailbox forwarding and automatic rules regularly, especially after an unusual account event.

11. Password Recovery Options Are Outdated

Recovery information can quietly become inaccurate. An old phone number, former employee’s email address, or unmonitored recovery method can create problems when an account needs to be secured or restored.

Confirm that recovery methods belong to the appropriate employee or organization and are protected appropriately.

12. No Clear Process Exists for Lost Devices

A lost laptop or phone can create access concerns if the device still has active sessions, stored credentials, or synchronized business files.

Businesses should know how to revoke sessions, remove company access, disable accounts, and manage business information on lost or retired devices.

13. Devices Are Not Part of Access Decisions

A valid username and password do not automatically mean the device accessing company data should be trusted.

Where available, device-based controls can help distinguish managed business devices from unknown or unmanaged equipment.

14. Google Workspace Settings Are Left at Their Defaults

Google Workspace security should include a review of administrator roles, two-step verification, external sharing, connected applications, mobile access, account recovery, and audit information.

Small companies often configure Google Workspace quickly and move on to other priorities. A later review can reveal settings that no longer match how the business operates.

15. Microsoft 365 Security Settings Are Not Reviewed Regularly

Microsoft 365 environments can change as employees, applications, licenses, devices, and business processes change. A configuration that made sense two years ago may no longer be appropriate.

Review identity settings, administrator roles, mailbox rules, application access, sharing policies, Conditional Access policies, and audit capabilities on a scheduled basis.

16. Security Logs Are Ignored

Cloud platforms can record valuable information about sign-ins, administrative changes, application activity, file access, and other events. Logs are far less useful if nobody reviews them.

Define which events deserve attention and establish a process for investigating unusual activity.

17. Unusual Sign-Ins Do Not Trigger Investigation

A login from an unfamiliar location, device, or application may have a legitimate explanation. It can also indicate that an account has been accessed by someone else.

Set appropriate alerts and investigate unusual sign-in activity instead of treating every notification as routine background noise.

18. Business Data Is Stored Without Clear Classification

Not every document requires the same level of protection. Payroll records, contracts, customer information, intellectual property, and general marketing material have different access requirements.

Classify important information and use that classification to guide permissions, sharing, retention, and access policies.

19. Backup and Recovery Assumptions Are Never Tested

Many businesses assume their cloud provider automatically protects everything they may need to recover. Cloud platforms provide important availability and recovery features, but businesses still need to understand what is covered, how long information is retained, and what recovery options are available.

Test critical recovery procedures rather than relying on assumptions.

20. No One Owns the Configuration Review

Perhaps the most overlooked gap is responsibility. If nobody owns the cloud environment, small configuration problems can remain unnoticed for months or years.

Assign an owner for reviewing accounts, permissions, applications, sharing settings, administrator access, alerts, and recovery controls. A documented cloud security checklist makes recurring reviews easier to manage.

The 20 Gaps at a Glance

A Practical Review Schedule for Small Businesses

A useful cloud security checklist should not sit in a document that nobody opens after the initial setup. Reviews should match the pace of the business.

Monthly: Check administrator accounts, former employee accounts, unusual sign-ins, external sharing, forwarding rules, and newly connected applications.

Quarterly: Review permissions, Conditional Access policies, recovery information, device access, cloud storage sharing, and important administrative changes.

After major changes: Review access whenever someone joins or leaves, a major application is introduced, a department changes responsibilities, or business-critical data moves between systems.

This approach makes configuration security part of normal IT administration instead of a once-a-year exercise.

What Should Small Businesses Prioritize First?

Not every business has the same exposure. A 10-person professional services firm, an online retailer, and a construction company may use different applications and store different types of information. Still, several controls deserve early attention.

Start with administrator accounts and MFA. Then review former employees, excessive permissions, external file sharing, connected applications, email forwarding, and recovery settings. After those areas are addressed, examine device access, logging, Conditional Access, and data handling.

This order helps businesses address high-impact configuration issues before spending time on less urgent improvements.

FAQ About Cloud Security for Small Businesses

What is cloud security for small business?

It is the process of protecting cloud accounts, applications, business data, devices, permissions, and configurations from unauthorized access or misuse. It includes identity controls, sharing settings, administrative permissions, monitoring, and recovery planning.

What are the biggest cloud security risks for small businesses?

Common risks include stolen credentials, excessive permissions, inactive employee accounts, broad file sharing, unauthorized application access, weak administrator controls, poor recovery settings, and overlooked cloud configurations.

How often should a small business review its cloud settings?

A basic review should happen regularly, with monthly checks for important account and access changes and deeper quarterly reviews. Major employee, application, or system changes should also trigger an immediate review.

Is Microsoft 365 secure for a small business?

Microsoft 365 provides many built-in controls, but the security of an environment also depends on how those controls are configured and maintained. Administrator roles, MFA, Conditional Access, sharing policies, application permissions, and audit settings deserve regular review.

Does Google Workspace need a security review?

Yes. Google Workspace security depends partly on how administrators configure accounts, verification requirements, sharing, connected applications, recovery options, and other controls. A review can identify settings that no longer fit the organization’s needs.

Close the Gaps Before They Become Openings

Attackers do not always need a sophisticated route into a business. An overlooked administrator account, an old application permission, an unrestricted sharing link, or a forgotten mailbox rule can create the opening they need.

A strong small business cloud security program starts with visibility. Know which accounts exist, who can access sensitive information, which applications are connected, what external parties can access, and which settings control those permissions. Then review those configurations consistently as the business changes.

Franklin Web Technologies can help businesses assess overlooked cloud configurations and identify practical areas for improvement. If your company relies on Microsoft 365, Google Workspace, or other cloud platforms, a focused configuration review can provide a clear picture of where access controls need attention and what should be addressed first.

Do not wait for an unusual login or unexpected data exposure to reveal a forgotten setting. Use the 20-point review above as a starting point, assign ownership, and make cloud configuration checks part of your regular IT routine.

Read more at Franklin Web Technologies

MFA and Conditional Access Solve Different Problems

MFA and Conditional Access are sometimes treated as competing options, but they are better understood as two layers of access control.

MFA asks, “Can this person prove they are the account owner?” A user may enter a password and then approve a sign-in through an authenticator app, use a security key, or provide another approved verification method. The additional step makes a stolen password less useful on its own.

Conditional Access asks, “Should this person be allowed to sign in under these specific circumstances?” It can evaluate signals such as the user, application, device, location, and sign-in risk before applying an access decision.

That distinction matters for small businesses. MFA provides a strong baseline for account protection. Conditional Access gives administrators more control over the circumstances in which access is permitted, blocked, or subject to an additional requirement.

What Does MFA Actually Do?

Multi factor authentication adds another verification requirement to the login process. Instead of relying only on a password, the user must provide another approved factor.

For example, an employee might enter their password and then approve a notification in Microsoft Authenticator. If someone obtains the password but cannot complete the second verification step, the login attempt can be stopped.

MFA is especially useful for businesses that want a practical improvement without creating a large set of access rules. It can help with:

• Reducing the value of stolen passwords
• Improving Microsoft 365 login protection
• Supporting account takeover prevention
• Adding an extra identity check for employees and administrators

MFA should generally be considered a baseline control for Microsoft 365 accounts, particularly for accounts with access to email, files, financial information, customer records, or administrative settings.

However, MFA does not by itself decide that a familiar user on an unmanaged device should be blocked from accessing sensitive information. That requires additional access policies.

What Does Conditional Access Add?

Conditional Access provides policy-based control over access to Microsoft cloud resources. Microsoft 365 administrators can create rules that evaluate the circumstances surrounding a sign-in and then apply a requirement.

For example, a business could require MFA for administrative accounts, block access from specific locations, or require an approved device for access to certain applications.

A Conditional Access policy can be designed around several signals, including:

Users and groups: Apply different rules to administrators, contractors, executives, or general employees.

Cloud applications: Apply stricter requirements to selected Microsoft 365 services or applications.

Device conditions: Require a compliant or managed device for specific resources.

Location: Apply different controls to trusted and untrusted network locations.

Risk signals: Use risky login policies to respond to sign-in or user risk signals when the appropriate Microsoft Entra capabilities and licensing are available.

This makes Conditional Access particularly useful for businesses with employees working from different locations, using company-managed devices, accessing sensitive resources, or handling different levels of information.

MFA vs Conditional Access: A Practical Comparison

The simplest way to distinguish the two is to think of MFA as an identity verification control and Conditional Access as an access decision framework.

The two controls are not normally an either-or decision. Conditional Access can actually be configured to require MFA when certain conditions are met.

When Should a Small Business Use MFA?

MFA is the logical starting point for a small business that currently relies heavily on passwords.

Consider a 12-person accounting firm where employees use Microsoft 365 email, OneDrive, and Teams. Staff work primarily from company-managed laptops and do not need different access rules for different locations.

The business may not need a large collection of access policies immediately. Requiring MFA for user accounts can provide a significant improvement while keeping administration manageable.

MFA is also useful when:

Your main concern is stolen passwords. MFA adds another verification step after the password.

You need a simple baseline. Businesses without dedicated IT staff may benefit from beginning with a straightforward control.

Most employees have similar access needs. If users generally access the same services under similar conditions, complex policies may not provide much additional value at first.

You are securing administrative accounts. Administrator accounts deserve particularly strong login controls because they can affect other users, applications, and settings.

When Does Conditional Access Make More Sense?

Conditional Access becomes more valuable as a business needs to distinguish between different access situations.

Imagine a 40-person consulting company with employees working from offices, client locations, and home. Staff use company laptops, but contractors occasionally need access to selected Microsoft 365 resources.

A single MFA requirement does not address every access scenario. The company may want employees using approved devices to access internal resources normally while applying stricter requirements to unmanaged devices or higher-risk sign-ins.

Conditional Access can help create those distinctions.

It is a strong fit when your business needs:

Different rules for different users. Administrators and contractors may require different access conditions.

Device controls. Access to selected resources can depend on device compliance or management status.

Application-specific requirements. Sensitive applications can receive stricter policies than general services.

Location controls. Certain access attempts can receive additional requirements or be blocked based on configured locations.

Risk-based decisions. Supported Microsoft Entra risk signals can help organizations apply additional controls to suspicious sign-ins.

For businesses using Microsoft 365 extensively, Conditional Access Microsoft 365 policies can provide much more precise control than a single MFA requirement.

Real SMB Scenarios

A Small Retail Business

A 10-person retailer uses Microsoft 365 for email, calendars, and documents. Employees work from one primary location and use a mix of company and personal devices.

Recommended starting point: MFA for all users, with stronger protection for administrator accounts.

Conditional Access can be considered later if the business needs device restrictions, location rules, or different access requirements.

A Professional Services Firm

A 30-person firm has employees working remotely and from client offices. Some users regularly access confidential client documents.

Recommended approach: MFA plus carefully designed Conditional Access policies.

The business could require MFA for users, apply device requirements to sensitive resources, and create additional controls for administrative accounts.

A Business With Contractors

A small technology company uses employees and external contractors. Contractors only need access to selected Microsoft 365 resources.

Recommended approach: MFA combined with Conditional Access.

Conditional Access can help apply different access requirements to contractor accounts and restrict access to selected applications.

A Business Concerned About Risky Sign-ins

A business has noticed unusual login activity and wants additional controls beyond standard MFA.

Recommended approach: MFA plus risk-based Conditional Access policies, using supported Microsoft Entra capabilities and appropriate licensing.

The objective is not simply to add more prompts. It is to make access decisions based on the conditions surrounding a sign-in.

SMB Decision Matrix

Use this matrix to identify the most appropriate starting point:

The matrix points to a useful rule: MFA is usually the starting control, while Conditional Access becomes valuable when the business needs context-based access decisions.

How to Avoid Overcomplicating Conditional Access

Conditional Access can be powerful, but poorly planned policies can create access problems. A business should avoid creating numerous rules simply because the technology allows it.

Start by identifying the accounts, applications, devices, and access situations that matter most. Build a small number of clear policies around those needs.

Test policies with appropriate users before applying them broadly. Keep emergency administrative access considerations in mind, and document why each policy exists.

It also helps to review policies after major changes, such as introducing remote work, allowing contractors, deploying managed devices, or adding sensitive applications.

Franklin Web Technologies can support this type of review by helping businesses connect access controls to actual operational requirements instead of adding rules without a clear purpose.

Do You Need MFA and Conditional Access Together?

For many businesses, the strongest setup is not MFA or Conditional Access. It is MFA with Conditional Access.

A Conditional Access policy can require MFA only when a particular condition exists. For example, an organization could require MFA for a specific application, apply stronger requirements to administrators, or respond to a higher-risk sign-in.

This layered model allows the business to keep MFA as a baseline while using Conditional Access for more precise decisions.

The right configuration depends on the organization’s Microsoft 365 licensing, applications, users, device management, and access requirements. Some Conditional Access and risk-based capabilities require specific Microsoft Entra licensing, so licensing should be checked before planning the final policy set.

Common Mistakes Small Businesses Should Avoid

The biggest mistake is treating MFA as a complete answer to every access problem. MFA improves identity verification, but it does not replace access policies.

Another mistake is creating Conditional Access rules without first documenting the business requirement behind each one. A policy should have a clear purpose, such as requiring MFA for administrators or restricting access from unmanaged devices.

Businesses should also avoid changing multiple policies at once without testing. A single poorly configured rule can affect many users.

Finally, do not overlook administrator accounts. A small number of highly privileged accounts can have a much greater impact than ordinary user accounts, so they deserve careful access controls and monitoring.

Frequently Asked Questions

Is MFA better than Conditional Access?

Neither control is a direct replacement for the other. MFA verifies identity using an additional factor, while Conditional Access determines access based on configured conditions. Most businesses should consider MFA a baseline and add Conditional Access when they need more precise rules.

Can Conditional Access require MFA?

Yes. Conditional Access policies can require MFA as a condition for accessing selected Microsoft resources or under specified sign-in circumstances. This is one reason the two controls often work together.

Does Conditional Access replace MFA?

No. Conditional Access can use MFA as one of its requirements, but it does not replace the authentication method itself. A business can use Conditional Access to determine when MFA should be required.

Is Conditional Access necessary for a small business?

Not every small business needs a complex Conditional Access setup. A small company with straightforward access requirements may begin with MFA. Conditional Access becomes more useful as the organization needs device, location, application, user, or risk-based access rules.

What is the difference between MFA and identity access management?

MFA is one type of identity and access control focused on verifying users through multiple factors. Identity access management is a broader discipline covering how users are identified, authenticated, authorized, and managed across systems and resources.

Can MFA prevent account takeover?

MFA can significantly reduce the usefulness of a stolen password because an attacker may still need the additional authentication factor. It should be combined with appropriate account, device, and access controls for stronger protection.

Choose the Control That Matches the Business Need

MFA and Conditional Access should not be viewed as competing products. They address different parts of the login and access process. MFA confirms more strongly that the person signing in is the legitimate account holder. Conditional Access determines what should happen based on the circumstances of that sign-in.

For a small business starting with basic Microsoft 365 protection, MFA is usually the first practical step. Businesses with remote workers, contractors, managed devices, sensitive applications, or more complex access requirements can add Conditional Access to create more specific rules.

A focused policy set is usually more useful than a large collection of rules that nobody fully understands. Review the business’s users, devices, applications, and access patterns first, then build controls around those real requirements. If you need help assessing your Microsoft 365 environment or planning an access policy structure, contact us for guidance on choosing an approach that fits your organization.

Read more at Franklin Web Technologies

DMARC, SPF and DKIM help receiving email systems confirm whether a message claiming to come from your business domain is properly authenticated. Together, they can reduce domain spoofing, support email deliverability, and give businesses more control over how their domains are used for email.

This guide explains DMARC, SPF and DKIM, what each email authentication standard does, how they work together, common DNS setup mistakes, and practical steps businesses can take to improve their email security.

For an SMB owner, marketing team, or IT administrator, these records are more than technical DNS settings. They can affect email delivery, brand trust, and protection against messages that try to impersonate your company.

When managing several email systems becomes difficult, Franklin Web Technologies can help businesses review their domain and email configuration and identify authentication gaps.

What Are SPF, DKIM and DMARC?

SPF, DKIM and DMARC solve different parts of the email authentication process.

SPF helps identify which systems are allowed to send email for a domain. DKIM adds a digital signature that receiving systems can verify. DMARC connects those authentication results to the domain shown in the visible From address and provides a policy for handling authentication failures.

Using all three provides a stronger foundation than relying on only one authentication method.

What Is SPF?

SPF, or Sender Policy Framework, is a DNS-based email authentication method that lists the systems allowed to send email for a domain.

For example, a business may send email through Microsoft 365, a CRM, and a marketing platform. The SPF record should include the approved services that are allowed to send messages for that domain.

A simplified SPF record might look like:

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

When a message reaches a receiving mail server, the server checks the sending IP address against the SPF policy for the email’s envelope sender domain.

The -all part means that sending sources not included in the SPF policy should fail the SPF check.

The exact SPF record will depend on the services your business uses.

SPF is useful, but it has an important limitation. It does not directly authenticate the visible From address that a person normally sees in their inbox. Email forwarding can also cause SPF authentication problems.

This is one reason DKIM and DMARC are important.

What Is DKIM?

DKIM, or DomainKeys Identified Mail, adds a digital signature to outgoing email.

The sending email service uses a private key to create the signature. A matching public key is published in your domain’s DNS records.

A simplified DKIM DNS record may look like:

Host: selector1._domainkey.example.com
Type: TXT

Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_VALUE

When the message reaches another email provider, the receiving system finds the public key in DNS and uses it to verify the DKIM signature.

A valid DKIM result shows that the email contains a valid signature connected to the signing domain. It also helps confirm that the signed parts of the message have not been changed in a way that breaks the signature.

Your email provider normally creates the DKIM keys and provides the DNS information you need to publish.

The selector, key length, hostname, and exact DNS value will depend on your provider.

What Is DMARC?

DMARC, or Domain-based Message Authentication, Reporting and Conformance, connects SPF and DKIM authentication with the domain shown in the visible From address.

For DMARC to pass, at least one supported authentication method must pass with proper domain alignment.

In simple terms:

• SPF can pass and align with the From domain.
• DKIM can pass and align with the From domain.
• If the required authentication and alignment conditions are met, DMARC can pass.

DMARC also allows the domain owner to publish a policy requesting how receiving email systems should treat messages that fail DMARC.

A basic DMARC record could look like:

Host: _dmarc.example.com
Type: TXT

Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

Common DMARC policies include:

• p=none — Used mainly for monitoring. No quarantine or rejection action is requested by the DMARC policy.
• p=quarantine — Requests that messages failing DMARC be treated as suspicious.
• p=reject — Requests the strongest handling for messages that fail DMARC.

Receiving providers can still use their own spam, security, reputation, and filtering systems when deciding what to do with a message.

DMARC reports can also give domain administrators useful information about which systems are sending email using their domain and where authentication problems may exist.

What Changed With DMARC in 2026?

DMARC guidance was updated in 2026 with the publication of RFC 9989, the current Standards Track specification for DMARC.

One important point is that businesses should not think of p=reject as the automatic final step for every domain.

Strict rejection can create problems with some legitimate email flows, including forwarded messages and mailing lists. For this reason, a business should understand how its email is being sent and forwarded before using a strict DMARC policy.

The safest approach is to review legitimate sending systems, monitor authentication results, fix alignment problems, and then decide which DMARC policy makes sense for the domain.

This is especially important for businesses using several email platforms, third-party senders, automated systems, forwarding services, or mailing lists.

How SPF, DKIM and DMARC Work Together

SPF, DKIM and DMARC are connected email authentication methods rather than competing technologies.

A simplified process looks like this:

Business sends email
        |
        v
Receiving mail server receives message
        |
        +----------------------+
        |                      |
        v                      v
     SPF check             DKIM check
        |                      |
        +----------+-----------+
                   |
                   v
            DMARC alignment
                   |
                   v
       Does SPF or DKIM pass
         with proper alignment?
                   |
          +--------+--------+
          |                 |
         YES                NO
          |                 |
          v                 v
 Authentication passes   Review DMARC policy
                         and receiver security
                              rules

The key point is that DMARC does not replace SPF or DKIM.

Instead, DMARC uses authentication results and checks whether the authenticated domain properly aligns with the domain shown in the From address.

Together, these technologies provide stronger email spoofing protection for domains used by employees, sales teams, customer service departments, marketing systems, and automated business applications.

A Practical SPF, DKIM and DMARC DNS Example

Consider a business using example.com for employee email while also using a separate provider to send newsletters.

Its DNS configuration might include the following records.

SPF

example.com TXT
v=spf1 include:spf.protection.outlook.com include:newsletter-provider.com -all

The SPF record identifies the approved sending services.

DKIM

selector1._domainkey.example.com TXT
v=DKIM1; k=rsa; p=PUBLIC_KEY_VALUE

The DKIM record provides the public key that receiving systems can use to verify signed email.

DMARC

_dmarc.example.com TXT
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

The DMARC record publishes the domain’s policy and provides an address where supported aggregate reports may be sent.

These are simplified examples only.

The actual DNS values should come from your email provider, CRM, marketing platform, or other sending service. Copying an SPF, DKIM, or DMARC record from another company’s domain can cause authentication or delivery problems.

SPF vs DKIM vs DMARC

The three standards perform different jobs.

SPF helps answer:

“Is this sending system authorized?”

DKIM helps answer:

“Does this message have a valid signature connected to the signing domain?”

DMARC adds another question:

“Does the authentication align with the domain shown in the From address, and what policy has the domain owner requested if it fails?”

This is why businesses should normally consider SPF, DKIM, and DMARC as parts of one email authentication strategy.

Common SPF, DKIM and DMARC Configuration Mistakes

DNS changes may look simple, but small configuration errors can affect legitimate business email.

Here are some of the most common problems.

Creating Multiple SPF Records

A domain should have one SPF policy record.

Creating separate SPF policy records for Microsoft 365, a CRM, a newsletter service, and other providers does not create several policies that automatically work together.

Instead, legitimate sending services generally need to be included in one SPF policy.

SPF also limits the number of DNS lookups that can be triggered during evaluation. The standard limit is 10 DNS-based lookups.

A complex SPF record that goes beyond this limit can create authentication failures.

Forgetting Third-Party Email Platforms

A business may correctly configure authentication for Microsoft 365 or Google Workspace but forget other services that also send email.

These may include:

• CRM systems
• Newsletter platforms
• Website contact forms
• Customer support systems
• Accounting platforms
• Booking software
• Ecommerce systems
• Automated notification tools

If these services are not properly configured, legitimate messages may fail authentication.

Create a complete list of every system that sends email using your domain before making major DNS changes.

Publishing the Wrong DKIM Record

DKIM depends on the correct selector, hostname, and public key.

Using the wrong selector, copying an incomplete key, publishing it under the wrong hostname, or missing part of the DNS value can cause DKIM verification to fail.

Follow the setup instructions provided by your email or sending provider.

Moving Too Quickly to a Strict DMARC Policy

A strict DMARC policy may be useful in some environments, but applying it without understanding your legitimate mail flows can cause delivery problems.

Forwarding, mailing lists, and third-party sending platforms can make authentication more complex.

Begin by understanding your sending environment and reviewing DMARC data before applying stronger enforcement.

Forgetting About Subdomains

Businesses often use subdomains for marketing, support, transactions, and automated email.

Examples include:

mail.example.com
support.example.com
news.example.com

Review how your DMARC policy applies to these subdomains.

Also make sure that every service sending from a subdomain has the correct SPF and DKIM configuration where required.

Leaving Old Sending Services in DNS

Businesses often change CRM, newsletter, or email providers but forget to remove the old service from their SPF configuration.

Leaving unused sending systems authorized can create unnecessary risk and make your DNS configuration harder to manage.

Review your records regularly and remove services you no longer use.

How Businesses Can Set Up Email Authentication

Do not start by changing several DNS records at the same time.

Start by identifying every system that sends email using your business domain.

This may include employee email, website forms, CRMs, newsletters, accounting platforms, booking systems, support tools, ecommerce platforms, and automated notifications.

Then work through the following steps.

1. Review your SPF record: Make sure all legitimate sending services are included and remove services you no longer use.
2. Enable DKIM: Obtain the correct DKIM settings from each email provider or sending platform that supports domain signing.
3. Publish DMARC: For many organizations, a monitoring policy such as p=none can be a useful starting point while legitimate mail sources are reviewed.
4. Review DMARC reports: Look for unknown sending systems, SPF failures, DKIM failures, and domain alignment problems.
5. Fix legitimate sending sources: Update DNS records or provider settings for systems that should be sending email.
6. Review forwarding and mailing lists: Understand whether legitimate messages pass through systems that may change authentication results.
7. Choose the appropriate DMARC policy: After testing and reviewing your email environment, determine whether none, quarantine, or reject is suitable for your domain.
8. Continue monitoring: Email systems change over time. Review your authentication configuration whenever you add or remove a sending platform.

For businesses without dedicated DNS or email expertise, Franklin Web Technologies can help review existing records, identify configuration gaps, and plan changes carefully.

Why Email Authentication Matters More for Businesses Today

A spoofed email may appear to come from a company executive, finance department, sales representative, support team, or trusted supplier.

A recipient may see a familiar company domain and assume the message is legitimate.

SPF, DKIM and DMARC give receiving email systems more information to determine whether a message claiming to come from your domain has been properly authenticated.

These controls are also increasingly important for email delivery.

Google requires senders to personal Gmail accounts to use SPF or DKIM authentication. Senders that send more than 5,000 messages per day to Gmail accounts must meet stronger requirements, including SPF, DKIM, and DMARC.

Yahoo also requires stronger authentication practices for bulk senders, including SPF, DKIM, and a valid DMARC policy.

For businesses sending newsletters, customer updates, promotions, automated messages, or large volumes of email, authentication is now an important part of both business email security and reliable email delivery.

What SPF, DKIM and DMARC Cannot Protect Against

Email authentication is important, but it does not stop every email threat.

SPF, DKIM and DMARC mainly help protect your actual domain from certain types of unauthorized use.

They do not automatically stop attacks involving:

• Lookalike or newly registered domains
• Display-name impersonation
• Compromised legitimate email accounts
• Malicious links inside authenticated messages
• Malware sent from an authorized account
• Social engineering attacks
• Every type of business email compromise

For example, an attacker may register a domain that looks similar to your real business domain and send properly authenticated email from that domain.

DMARC for your real domain cannot directly control another independently registered domain.

This is why authentication should be one part of a wider phishing protection and email security strategy.

SPF, DKIM and DMARC Are Not the Same as Spam Filtering

Email authentication and spam filtering perform different jobs.

SPF, DKIM, and DMARC provide information about the identity and authentication of a message.

Email providers can combine those signals with many other factors when deciding whether to deliver a message, send it to spam, block it, or apply additional checks.

A message that passes DMARC is not automatically safe.

An authorized or compromised account can still send unwanted or harmful email.

In the same way, an email that fails authentication is not automatically an attack. A legitimate third-party platform or forwarded message may have an authentication or alignment problem.

This is why DMARC works best as part of a broader email security strategy rather than as a single security control.

Frequently Asked Questions

What is the difference between SPF, DKIM and DMARC?

SPF identifies systems that are allowed to send email for a domain. DKIM adds a digital signature that receiving systems can verify. DMARC checks whether SPF or DKIM authentication aligns with the domain shown in the From address and provides a policy for failed authentication.

What happens if a domain does not have DMARC?

Without DMARC, the domain does not provide receiving systems with a DMARC policy or DMARC alignment instructions.

SPF and DKIM can still provide authentication results, but DMARC connects those results with the visible From domain and can also provide reporting information.

Is SPF enough without DKIM?

SPF alone is generally not the strongest approach for modern business email.

Email forwarding and complex third-party sending arrangements can cause SPF problems. DKIM provides a separate authentication method, while DMARC can use properly aligned SPF or DKIM authentication.

Using SPF and DKIM together gives businesses more options for successful authentication.

Can I use DMARC without SPF?

DMARC can pass through properly aligned DKIM even when SPF does not provide an aligned pass.

However, businesses should normally configure both SPF and DKIM when their email systems support them. Using both provides stronger and more flexible authentication.

Why can SPF fail when an email is forwarded?

SPF checks the sending IP address against the SPF policy for the envelope sender domain.

When an email is forwarded, the system sending the forwarded message may not be listed in the original domain’s SPF record. This can cause SPF to fail even when the original message was legitimate.

DKIM can sometimes continue to verify through forwarding if the signed parts of the message have not been changed.

What does p=none mean in DMARC?

p=none means the domain owner is not requesting quarantine or rejection based only on the DMARC policy.

It is commonly used while businesses review authentication data and identify legitimate sending services.

Receiving email providers can still use their own spam, security, and reputation systems when deciding how to handle the message.

Should every business use p=reject?

Not automatically. A p=reject policy requests strict handling of messages that fail DMARC, but it may affect some legitimate forwarded messages, mailing lists, and other indirect email flows.

Businesses should review their authentication reports and understand how legitimate email travels before choosing a strict DMARC policy.

How long does DMARC take to work?

The DNS record may become available fairly quickly, but the exact timing depends on DNS caching and TTL settings.

The larger task is usually monitoring reports, identifying legitimate sending systems, fixing authentication problems, and deciding which policy is appropriate.

A complete DMARC rollout may therefore take longer than simply publishing the DNS record.

Can DMARC stop every spoofed email?

No. DMARC helps receiving systems deal with messages that falsely claim to use your protected domain.

It cannot directly stop attackers from registering similar-looking domains, using compromised legitimate accounts, or impersonating an employee through the display name.

Do Google and Yahoo require SPF, DKIM and DMARC?

Google and Yahoo have email authentication requirements for senders. Google requires SPF or DKIM for senders to personal Gmail accounts and stronger requirements for bulk senders. Senders delivering more than 5,000 messages per day to Gmail accounts must use SPF, DKIM, and DMARC. Yahoo also requires SPF or DKIM for general senders and stronger authentication, including SPF, DKIM, and DMARC, for bulk senders. These requirements make proper email authentication important for both security and reliable email delivery.

Build a Stronger Email Authentication Foundation

SPF, DKIM and DMARC give businesses practical tools for showing which systems are authorized to send email and helping receiving providers evaluate messages that claim to come from their domains.

The best results come from configuring all three carefully, keeping DNS records accurate, and reviewing your setup whenever your business adds or removes an email platform.

Start by auditing your current SPF, DKIM, and DMARC records instead of making several DNS changes at once.

Identify every legitimate sender, review authentication and alignment problems, remove outdated sending services, and monitor DMARC reports before choosing a stronger policy.

Get in Touch Today if your business needs help reviewing its email authentication setup, identifying DNS configuration problems, or planning a safer DMARC rollout.

A properly maintained email authentication setup can support stronger domain protection, more reliable business communication, and better defense against messages that attempt to impersonate your organization.

Read more at Franklin Web Technologies

Read more at Franklin Web Technologies

Read more at Franklin Web Technologies

Read more at Franklin Web Technologies

Read more at Franklin Web Technologies

Read more at Franklin Web Technologies