What are Barracuda filter rules and how are custom rules created?
Michael Ko
Co-founder & CEO, Suped
Published 6 Jul 2025
Updated 22 May 2026
10 min read
Summarize with
Barracuda filter rules are the individual checks, scores, policies, and allow or block decisions that a Barracuda email security product applies to a message. A 'Custom Rule' in a spam report does not automatically mean your vendor created it. It can be a Barracuda-supplied private rule, a third-party ruleset entry, a local administrator rule, or a pattern filter created in the GUI.
Custom rules are created by an administrator in the Barracuda policy interface. The admin chooses a scope, such as a domain, recipient group, user, or organization, then chooses a condition, such as sender, IP, domain, header, body phrase, URL, attachment type, or authentication result. The rule then applies an action, usually allow, block, quarantine, tag, redirect, or add score.
- Owner: Treat the label as evidence, not proof. Ask who owns the rule and where it is configured.
- Evidence: Use the full headers, rule name, score, product version, recipient domain, and timestamp.
- Fix path: Fix the message cause first, then ask for a rule exception only when the rule is too broad.
The short answer
The clean answer is this: Barracuda has product-supplied filtering rules and customer-created custom rules, and both can show up in a result as 'custom'. That wording is why these reports create confusion. A rule such as MJ019, MV1123, MV0615, or SA038b is usually an internal identifier, not a public explanation.
Do not assume local ownership
A custom label can come from a shipped private ruleset, a managed vendor rule, or a local admin policy. I never treat the word custom as proof that the receiving company manually wrote the rule.
- Low score: A small score often means one signal in a larger spam-scoring model.
- High score: A larger score deserves owner confirmation because it can drive quarantine or rejection.
- No definition: Private rule details are often withheld to stop senders from gaming the filter.
If a vendor says the rule is from Barracuda, that answer is plausible. It is still incomplete unless they can say whether the rule is shipped, vendor-managed, tenant-created, or inherited through a managed policy.
What a Barracuda filter rule does
Barracuda scoring looks like many spam-filter reports: each rule contributes points, then the total is compared with tag, quarantine, and block thresholds. The same message can pass DMARC, SPF, and DKIM yet still lose points because of links, headers, content patterns, sender reputation, recipient policy, or a blocklist (blacklist) signal.
Example Barracuda-style spam reporttext
X-Barracuda-Spam-Status: No, SCORE=2.70, TAG_LEVEL=3.0 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.92409 pts rule name description ---- ------------------ -------------------------- 0.25 BSF_SC0_SA038b Custom Rule SA038b 2.00 CUSTOM_MV1123 Custom rule MV1123 0.00 HTML_MESSAGE BODY: HTML included in message
An older Barracuda explanation shows the same general idea: Barracuda headers can expose score, threshold, rule names, and a report section. The thresholds in your own header matter more than any generic example.
Example scoring bands
Use the threshold values in the actual header when they are present.
Delivered
0-2.9
Below the tag level
Tagged
3.0+
Subject or header marking
Quarantined
5.0+
Held for review
Blocked
7.0+
Rejected or dropped
Where custom rule labels come from
I split the source into four buckets. This keeps the conversation with the vendor practical, because each bucket has a different fix path.
|
|
|
|---|---|---|
SA038b | Private shipped rule | Is this Barracuda-owned? |
MV1123 | Managed vendor rule | Who can change it? |
MJ019 | Tenant policy | Which policy matched? |
KAM | Third-party ruleset | Which source list? |
Common sources behind custom-looking Barracuda rules.
A Server Fault discussion reached the same practical point years ago: some Barracuda custom rule codes are internal and do not have public definitions. That does not make the score useless. It means the header must be paired with message samples, product version, and policy owner.
If the report also includes SpamAssassin-style names, compare those separately. SpamAssassin rules are easier to research when the rule name is public, but Barracuda-specific rule codes often stay private.
How custom rules are created
The exact screen names depend on whether the organization uses Barracuda Email Gateway Defense, an Email Security Gateway appliance, a managed service, or another Barracuda policy product. The workflow is still consistent: choose scope, choose conditions, choose action, then test. Barracuda's Barracuda advanced filtering documentation shows this pattern with user or group scope, allow or block action, and category, domain, or URL rule types.
- Scope: Apply the rule to the smallest domain, recipient group, or user set that solves the issue.
- Condition: Match one clear attribute, such as sender domain, URL domain, header, body phrase, or attachment.
- Action: Choose allow, block, quarantine, tag, redirect, or score change based on the risk.
- Order: Place exceptions above broad rules when the product uses precedence ordering.
- Audit: Record the reason, owner, creation date, expiry date, and a sample message.
Barracuda Email Gateway Defense policy screen showing custom rule fields.
The safest custom rule is narrow, named clearly, and reviewed. A broad allow rule for an entire sending domain can hide abuse. A narrow exception for a specific sender, recipient group, and message stream is easier to monitor and remove.
How to tell if a rule is local or shipped
No single clue proves ownership, so I use a short evidence chain. Start with the exact rule identifier, then look for the policy owner, the score, and whether the admin console shows a matching custom policy.
Signals of a shipped rule
- Pattern: The rule uses an opaque short code with no tenant-facing name.
- Visibility: The administrator cannot find a matching editable rule in the policy UI.
- Change path: Only support or a rule update can explain or tune it.
Signals of a local rule
- Name: The rule maps to a named policy, sender rule, phrase filter, or URL rule.
- Scope: It applies only to one recipient group, business unit, or tenant.
- Owner: A local admin can change priority, condition, or action.
Flowchart for finding whether a Barracuda custom rule is local or shipped.
This matters when a sender is blocked even though the sending IP is not on public blocklists. A private content rule, URL rule, recipient-level policy, or reputation signal can still trigger filtering. That is also why Barracuda blocking needs more than a public blacklist lookup.
What to ask the vendor or admin
The useful question is not 'What does this secret rule mean?' The useful question is 'Which controllable condition caused this message to score, and who can confirm the rule source?' I ask for the answer in a structured way so the support team cannot reply with only a generic statement.
Rule clarification requesttext
Message ID: <paste full Message-ID> Recipient domain: example-recipient.com Sending IP: 192.0.2.10 Rule shown: CUSTOM_MV1123 Score added: 2.00 Header timestamp: 2026-05-23 10:45 UTC Please confirm whether CUSTOM_MV1123 is: 1. Barracuda-supplied 2. vendor-managed 3. tenant-created 4. inherited from a shared policy Please also confirm the matched condition category and action.
What counts as enough detail
- Category: Content, URL, sender, authentication, attachment, reputation, or policy.
- Control: Whether the receiving admin, vendor, or Barracuda support can change it.
- Remedy: Whether the right fix is message cleanup, authentication repair, or policy exception.
If the answer points to a Barracuda blacklist or reputation listing, switch to a removal workflow. The steps in Barracuda blocklist fixes are different from the steps for a private content rule.
How to validate the sending side
Before asking for a custom rule exception, prove that the sending domain is cleanly authenticated and that the message itself is not creating avoidable scoring. I start with a real test message because DNS alone cannot show the final headers, MIME structure, links, and content.
For most teams, Suped is the best overall DMARC platform to pair with this work because it separates Barracuda filtering from authentication and reputation problems. Suped brings DMARC, SPF, DKIM monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, issue detection, fix steps, and blocklist monitoring into one workflow, so a custom rule result becomes part of a larger investigation instead of a dead end.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Use the email tester when you need to inspect a real message, then use a domain health check when you need a broader DNS and authentication read. If the sending side is clean, the discussion with the receiving admin becomes much sharper.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Guardrails for creating custom rules
Custom rules are useful, but they age badly when nobody owns them. The rule that solves one vendor issue today can become the exception that lets unwanted mail through six months later. I prefer rules that expire, rules with tickets, and rules that match a narrow, observable attribute.
A safer rule pattern
- Narrow match: Use a specific sender, domain, header, URL domain, or recipient group.
- Documented reason: Tie the rule to a ticket, sample message, business owner, and review date.
- Measured outcome: Check whether the rule changes delivery without hiding authentication failures.
The same discipline applies during warm-up, list migrations, and new domain launches. If Barracuda filtering starts during warm-up, compare the custom rule evidence with Barracuda and Yahoo blocking patterns before adding a permanent exception.
Views from the trenches
Best practices
Keep rule evidence tied to one message header, one timestamp, and one sending IP address.
Ask the filtering admin for action, scope, and source before changing the message.
Separate public blacklist checks from private content and recipient policy analysis.
Common pitfalls
Treating every custom label as a local admin rule leads to the wrong escalation path.
Changing subject lines or templates blindly hides the signal and wastes test cycles.
Ignoring rule versions makes repeat tests hard when Barracuda updates rulesets later.
Expert tips
A small custom score still matters when it combines with URL, header, and content scores.
Ask for a policy export or screenshot when a vendor claims the rule is locally created.
Use one controlled test message at a time so the rule owner sees the exact trigger.
Expert from Email Geeks says Barracuda appliances can contain shipped rules labelled as custom rules, while administrators can also create local custom rules.
2022-03-23 - Email Geeks
Marketer from Email Geeks says vendors often cannot publish every private rule definition because the rulesets change frequently and include many patterns.
2022-03-24 - Email Geeks
The practical takeaway
Barracuda filter rules are scoring and policy checks. Custom rules are created in the admin policy interface, but a 'Custom Rule' label in a result does not prove the receiving admin created it. It can be shipped, private, vendor-managed, or local.
The fastest path is to collect the full header, identify the score and threshold impact, ask who owns the rule, and validate the sending side with real message evidence. When a rule is local, narrow it and document it. When it is shipped or private, fix the message and reputation signals you can control, then escalate with precise samples.
